One of the most important things an engineer or engineering manager can learn to do is delegate. Unfortunately, engineers are generally pretty terrible at delegating. As an engineer myself, I think I know why. We’re perfectionists. Our way is the only way. Combine that with a solid work ethic, and delegation just ain’t gonna happen. “I’ll do it myself, thank you very much.” says the overworked engineer.

While there is definitely something to be said for being particular about your work, there are some serious downsides to avoiding delegation. After nearly 10 years as an entrepreneur and more recently as an engineering manager in a big company, I have learned a lot about delegation and what it can do for you.

Mark my words, delegation is an incredible thing.

Today, I want to share the lessons I’ve learned about delegation, and show you exactly why, when, and how to delegate so that you can take control of your work or your business.

The downsides of denouncing delegation

If you’re a typical engineer, you probably don’t do a lot of delegating – even if you could or should be. As I mentioned above, passing work off to others can be a scary prospect for some. In other cases, people just know know how to delegate properly, so when they try it and things go terribly they think to themselves “If you want something done right, you’d better do it yourself.”

Unfortunately, there are some major problems with avoiding delegation at work or in your business.

Consider this:

• Most engineers are overworked as it is – avoiding delegation (or delegating poorly) means that they stay overworked (and stressed)
• Sometimes, the work engineers get assigned isn’t a strong fit for that engineer’s skills, or is uninteresting to that person, leading to boredom and disengagement. Despite this, they do the work anyway.
• When you allow yourself to be overworked, the quality and punctuality of your work slips (which makes you more stressed)
• Junior engineers don’t get the opportunity to learn new skills when the work could easily be passed on to them.
• Other engineers who need extra work can’t get it.

It’s clear that engineers and their managers should try hard to delegate work to others in these circumstances. Both the engineer and the people around them stand to benefit.

Delegation delight

Given the downsides of delegation, the upsides should be clear. They’re just the opposite of the negatives.

Delegation is great because:

• It frees you to work on fewer, more important or more interesting things
• By focusing on fewer things, you can be more effective and efficient, which leads to lower stress and better engagement.
• Junior engineers get a chance to learn new things and grow their skills.

That last item definitely hits home for me. When I was a junior engineer, I worked under a brilliant man who was an associate in the firm. The problem was that he was perpetually swamped. He hardly left the office. He even slept there sometimes. Despite his being overworked and overtired, he couldn’t (or refused to) make the time to pass some of his work to me. I wanted the work because I wanted to learn more about electrical engineering, but I never got that chance under him. It was a very difficult situation, and one that could have easily been resolved had he been a strong delegator.

With that, I hope that you agree that delegation is an important skill for engineers and managers to have and to use.

Delegation dos and don’ts

With all that being said, how do you actually go about delegating something to someone? In this section, I want to explain exactly that.

The first and probably most important thing to think about is why you delegate.

Why delegate?

Let me be clear: delegation is not about avoiding work. It’s about making room for other, more important or better-fitting work. I’m not recommending delegation as a means of getting out of having things to do. You’re paid (I hope!) to be an engineer, so you had better make sure you get some engineering done in the run of the day. The power of delegation is in its ability to clear space for that specific work that you really should be doing.

So if that’s the case, why might somebody delegate something? Here are a couple ideas for why you might delegate something:

• You don’t have the capacity to get a newly assigned task done on time or with the right quality.
• You don’t have the skills to complete the task.
• Somebody else could benefit from completing the task under your guidance (think skills development for junior engineers).
• Somebody else is short on work and you don’t need the extra work.

If any of these situations apply to you, you should really think hard about passing the new work along to somebody else.

When to delegate

In short, you should delegate tasks as soon as humanly possible. When you’re assigned a task you need to make a quick decision as to whether you should delegate the task or not. Look through the bulleted list above. If any of those items apply to you, delegate, and do it quickly.

There are a few reasons why you want to be fast about making this decision:

• Delegation takes time and effort. Delegation isn’t a complete elimination of all work associated with a given task. Generally, it’s a lot less work than the task itself which is what makes delegating worth it. You need to give yourself time to actually DO the work of delegating.
• The person you have in mind might not be available. Then you’ll need to find someone new, or decide to do the work yourself. In either case, the sooner you sort that out the better.
• In most cases, you’ll still be accountable for the work. You can delegate responsibility for doing the work, but you cannot delegate accountability  for ensuring it gets done. This is a bit like being a CEO. Shareholders recognize that a CEO isn’t responsible for doing all the work there is to do in an organization, but they do see the CEO as accountable for ensuring all the work gets done. This being the case, you’ll want time to review the work that was done by your junior before submitting it. This takes time.

As with most decisions in life, the sooner you make the call to delegate, the better.

How to delegate

Now that we know why and when to delegate, we need to talk a bit about how to actually delegate. In my experience, the best way to do this is to treat the activity a bit like a mini project. If you’ve ever done any project management, you know that a project is defined by it’s scope, schedule, and budget. When you delegate something to someone, you need to make sure that you cover these three things.

Scope

There are a number of things you should consider with respect to scope. What exactly do you need done? What are the specific deliverables you need produced? Are there any constraints or requirements that need to be taken into account?

The scope should define – very precisely – the work that needs to be done. However, it’s important that scope not include how the work needs to be done. Telling someone what needs to be done is delegation. Telling someone how to do it is micromanaging. It’s important to give people the freedom to try things their own way, and to make yourself available to them if they have questions or need guidance.

Another important element to scope is answering the question “Why does this need to be done?” People generally value knowing that their work is important – that there is in fact a reason for doing the work. Knowing why the work needs to be done can also serve to help make decisions on how to tackle the work. Knowing, for example, that a certain task is meant to support a client presentation as opposed to an internal design review may influence how a delegate approaches the task.

Schedule

When does the task need to be completed by? Does this include reviewing the deliverables with you? Are there milestone deadlines that need to be met? This can be a bit awkward for some people, but you need to be clear about your expectations on when (down to the time of day, if need be) a deliverable needs to be delivered. If you don’t assign a deadline, then the task can never actually be late, so the task will likely never get done, and you’ve got no recourse for that.

Budget

How many hours/ dollars are available for this task? Is there a specific charge code or anything that your delegate should be made aware of? Similar to schedule, your delegate needs to know what they’re working with.

How to physically delegate a task

Once you have the scope, schedule, and budget set, you’re ready to actually delegate. Here’s how I approach delegating a task:

1. Write up a memo explaining the scope, schedule, and budget.
2. Talk to the potential delegate’s supervisor to get their permission/ buy-in first. Give them a copy of the memo you wrote for their consideration. If you don’t have that manager’s blessing first, you might as well stop then and there. It can help to emphasize why the task is important (discussed earlier) and how it will benefit the delegate.
3. If you have the manager’s support, have a conversation with the delegate to explain what you’d like. Emphasize the “why” of the task. They need to understand that the task is actually important and not just “scut” work. If it is scut work, hopefully it’s still important for some reason. If it’s not important then you really need to ask yourself why anybody is completing this task.
4. If the delegate is on-board, send the memo to the delegate and copy their manager. If they aren’t supportive, then you may need to modify the scope, schedule, or budget to address their concerns, or find a new delegate.
5. 24 hours later, I *highly* recommend you touch base with the delegate to make sure they’ve started the task, and that they understand. Take the time to answer questions they may have. Taking the time now can save you a mountain of work later on. I’d do another check in within 5 days as well.

Delegation domination or disaster?

What experience have you had with delegating a task or being delegated a task? What works? What doesn’t? What advice would you give to the E&L community? Take a minute and leave a comment below to share with us!