Chapter 8: A Real-Life Handbook for Making Delegation Work for You

Delegation.

You’ve heard the legends. You’ve maybe even seen this miracle management technique in action. You know that absolutely everyone sings its praises even as they struggle to implement it.

But as an agency owner, how do you make the magic of delegation work for you?

I’m not here to blow sunshine at you. Even after years of experimenting with and observing management until I got it right, I still have management failures when it comes to delegation.

The difference now is that when I hit a delegation snag, I can course correct on a dime and get the ship headed to its destination. And these days, I have to do that less and less because I know how to read the charts and steer around the hazards.

Let’s dive into one of these typical problems now.

Delegation Fail: The Best Laid Plans…

Just a few weeks ago, I had the chance to put my delegation skills into action—from both sides of the management table.

The setup

I manage a team of developers with Ryan. He handed my team a new project that he knew inside and out, but needed us to execute.

After looking at the project requirements, he figured that he could get the job done in two weeks, so he handed off his notes and budgeted one developer to finish the job in three weeks, just to be on the safe side.

Five weeks later, we still weren’t finished, even with three coders hammering away.

That Painful Moment

Quite understandably, Ryan was upset. In fact, he was really upset. Instead of ranting and raving though, he simply moved the other programmers aside, shuffled his own workload around, and he picked up the tools.

Ryan dropped everything and spent a week getting the project in shape while the rest of us stepped back and carried on with the rest of our work in an uncomfortable silence.

Back to the team

Clearly, we needed to have a meeting for me, Ryan, and the developers so we wouldn’t have an episode like this again.

It wasn’t a pretty scene.

As painful as this moment was, I wanted the team to learn as much as possible from this ugly situation so we would avoid it at all costs in the future.

In a private meeting beforehand, I asked Ryan to call a team meeting to hold my toes to the fire over this—in front of everyone. Ryan’s not a yelling kind of guy, so I had to encourage him to raise his voice a bit to get the team’s attention.

Why the drama? The team needed to have complete awareness of the stakes in this game. We needed to ask the painful, necessary questions and face the difficult answers.

In that tense environment, it came out that even though Ryan thought he had been completely clear on his expectations, the team—including me—misinterpreted his instructions. For weeks, we were pushing ahead to create something radically different than what he had envisioned, even though we thought we knew what he wanted.

Ryan thought he handed off a carefully labeled road map, but when we looked at it, we saw another path and destination entirely.

Delegation: It’s Always About Communication

Here’s the biggest misunderstanding I see with delegation.

Most people think it’s wonderful because they get to pass off less rewarding work to someone else—and it still gets done! And that is magical.

But there’s a deeper beauty of delegation.

There is nothing like the experience of taking an idea that only existed in your head—that you assumed no one else could quite understand the way you do—and see it completed in all its glory through the effort of many people working together.

Doing delegation well creates so much value that I want you to have a really good handle on how delegation actually works.

The key to having more great delegation moments is not just providing clear communication about your vision, but making sure is received and understood by the very people who will be implementing it.

Fear not. I am not about to start rambling on about touchy-feely communication skills that will take you years to perfect. Instead, let’s break down the delegation problem like real programmers.

Bugs in Your Delegation Process

Basically, glitches in the delegation process come down to two types of errors: compile-time and run-time bugs.

Compile-time bugs crop up in delegation when when you haven’t been careful with the syntax. In other words, you haven’t verified understanding when you communicated expectations to your team and made sure your that your plan was understood.

The result is that you get a completely different outcome than you needed—or the project can’t move forward at all.

Run-time bugs appear in delegation well into a project when you haven’t checked on progress at regular intervals. You cross your fingers and figure that after another 24 hours or week, things will work themselves out. I mean, your team is competent, right?

The result of run-time errors is that you don’t know how wrong the project is until the last minute, causing missed deadlines and contributing to a real last-minute disaster.

Let’s take another look at this issue.

Errors in action

Think of delegation problems this way: Your company needs to produce the Mona Lisa. You hold a meeting to give your programmers notes and instructions about this amazing portrait you want to produce in three weeks. Then you turn them loose, expecting great things.

Three weeks later, the team, eager and proud, hands you a perfectly executed drawing of…

… a ’69 Ferrari.

Oops.

The compilation error happened when you didn’t check for the team’s understanding of your instructions at the beginning of the process.

You caused the run-time error by neglecting to ask for preliminary sketches and by skipping regular, real-time progress reports to see exactly what was on the drawing board.

So it’s all the manager’s fault?

In a word, yes.

And while that seems overwhelming and unfair, remember that if this much responsibility is in your hands, you also have a tremendous opportunity to identify and head off the problems before they cause a lot of drama and angst.

Debug Your Delegation Process

I’m unapologetically relentless on the point that effective management depends on effective communication. Here is my best advice on strategically and smoothly integrating feedback into the normal workflow.

Check Understanding: Best strategies to combat compile time bugs

• Open a conversation. At the very beginning of the process, check for understanding. Insist on a kickoff or design meeting where all of the issues can get on the table.

• Plan, plan, plan. Put some muscle into project prep through written instructions, sketches, and concept description for this opening meeting to eliminate confusion and loose ends. Don’t leave essential issues to chance. Unfortunately, people may not take the time to read all of your notes, so walk through the details with the essential players and verify that they understand expectations. Realize that many people are “visual thinkers”, so don’t skimp in the diagrams and wireflows. You’re not creating “bureaucracy”, you’re communicating an idea, and it takes work.

• Expect and encourage questions. Be humble enough to ask,” What am I missing? I know I’m overlooking something. What issues could use some clarity before you dig in?” Don’t assume people “get it” the first time, and work to know the communication styles of your team, so you can communicate effectively.

• Cultivate a safe environment for questions, always. Every project has questions that only appear as the project moves along, especially if you’re using an agile development approach. Reward those who have the courage to ask and/or give you bad news early in the process, when there’s still time to fix it.

• Realize the complexity of what you’re doing. Effectively communicating technical tasks is an intricate job, so don’t get rattled by layers of unanticipated questions that emerge.

Check Progress: Best strategies to combat run time bugs

• Don’t become an infinite loop error. Check in with programmers early and often rather than giving them the benefit of the doubt (or unreasonable optimism) and leaving them to do their own thing.

• Follow your gut. When you get that internal sense telling you to kick back and “give things a little more time,” that’s the signal to check in with your team. Most likely, something needs attention—now.

• Schedule well-timed check-ins. If a project is due Friday at noon, don’t wait until Thursday at quitting time to get a progress update. If there are new people on your team, touch base more frequently so they get comfortable with a higher level of contact.

• Make your interaction quick and painless. Stop by individual desks for short stand-up meetings to hear what’s happening. If you’re using Agile development, these touch points are as essential as breathing.

• Do an actual test drive of the progress. If you’re making furniture, it’s easy to see progress. Just count the number of finished tables or cabinets! With programming, accomplishments are harder to see at a glance, so (politely) ask for a little proof so you can catch problems early.

What if You Get a Ferrari Anyway?

Sure, a Ferrari is a beautiful thing, but not if you were expecting a Mona Lisa.

Even when you think you’ve done everything right (as Ryan and I thought we did), bugs can still creep in.

What can you do when it feels like it’s too late?

1. Start by taking responsibility for the miscommunications. Blaming team members and insisting “they just don’t get it” doesn’t move the project or the team forward. In fact, it’s very harmful to morale and loyalty.
2. Identify the root of the problem. Where did the project start heading off the rails? Did you ignore your intuition when it was nudging you to check in? Were team updates too vague and untested?

I’m really a big fan of delegation. Though it can be bumpy and unpredictable, but the rewards for you and your team are huge.

Take a breath, set aside misconceptions and fears, and commit to a more hands-on approach with communication. Once you and your team learns to trust the process, it’s a gift that keeps on giving.

[sc:post-footer-optin]