In this paper, you'll learn a simple system for delegating work. Successful delegation may require you to change your thinking and will require you to let go of how the work gets done. You will learn EXACTLY how to delegate work (that stays delegated AND delivers great results). This works, even if your team members don't have all the skills they need.
My goal for you is to clearly understand:
- The Delegation Problem;
- How to Develop a New Mindset; and
- Defining the 30% Solution.
I will discuss a simple, specific approach where you provide direction and guidance to the team member at the beginning of the work package and again, at the end of the work package, allowing them to carry the majority of the work out on their own.
I call this approach “The 30% Solution.” It will free up your time, help you get more work done by others, and at the same time, will help project team members develop important skills which you can use in future engagements.
Introduction
In order to be successful, project managers need to balance technical skills in project management with “soft skills” in people leadership. As you work your way through leading people, one of the most difficult transitions is one that I refer to as “crossing the chasm.”
We start our careers as technical experts. When we become a leader, our technical skills are important, but actually become less valuable than our ability to influence others–to lead them.
To be the most effective in your role as a leader, you will need to change your mental model. You will not succeed solely because of your individual effort. Your success will come from achieving larger business goals through orchestrating the work of others.
Even when we, as project managers, recognize that we need to think differently about project success, we often do not have the specific skills or resources to delegate well.
Many times, we attempt to delegate using ineffective methods like making task assignments through a ticketing system or email. Much of the needed information is “lost in translation” and the low personal connection of those tools leads to low commitment on the part of the person assigned to do the work.
Even when the team member turns in work by the requested date, many times it's just not good enough, leading to delays and costly rework. After this happens a few times, project managers can resort to “doing it themselves” so that they are assured of the quality and timely delivery of work packages.
This leads to failure, because nothing of significance can be done by a single individual.
Project managers need a new way of thinking and a simple set of skills to improve their project performance.
The Delegation Problem
1. When we are busy and overwhelmed, we need to delegate.
Exhibit 1: Overwhelmed employees are an urgent trend.
We have been challenged over and over to do more with less. Our work assignments get bigger and bigger and our staff gets smaller and smaller. Internet access to tools and mobile devices makes us more accessible than ever before, and the lines between “work” and “personal time” have become blurrier. In short, we are all too busy.
In fact, I believe that many of us are too busy to think. We focus on doing. That hurts us.
2. When we fail to delegate, we are letting ourselves down AND we are letting our teams down.
As project managers, we are not paid to do the technical work of project management. We are paid to deliver a business result. Senior leaders look at our work as an investment with the promise of significant return. They are counting on us to make the right choices to effectively transform their budgeted dollars into business results.
Exhibit 2: IT projects deliver less functionality than originally promised.
When we focus our time and attention on the tasks rather than the business problem and the business result, we “major on the minors.” Too often we fail to do what we are paid to do. Even if our projects are on time and on budget—we experience a “benefits shortfall” where the business does not realize all of the benefits promised in the project charter (Exhibit 2). We are investing our time on the wrong things—we are cheating ourselves and we are cheating the business.
Project team members almost always want to improve their skills and deliver more business value as a part of developing in their careers. When we fail to delegate effectively, we fail to offer them the significant career experiences that they need to grow into the effective leaders our organizations need.
Exhibit 3: Decisions about what can be delegated.
As you're deciding what to delegate, think about your team member.
3. Most of us don't know how to effectively delegate the work in front of us.
Even if we believe that delegation is needed, and we try to do it, many times we don't know how to do it well. This leads to disappointment, frustration, project delays, and increased expense to our organizations.
Exhibit 4: Delegation saves knowledge workers time.
We have not seen enough good models of delegation to help us know how to do it well. We attempt it, but we don't like the outcomes we get. We give up and we end up re-doing a bunch of the work ourselves in the hopes of getting the project done so we can move to the next one.
Susan's Trap
Susan is a leader in a large organization. She became a project manager after demonstrating skill in getting technical work done. She is an achiever. Because she was so good at making things happen, her boss asked her take on responsibility for leading the team (in addition to her “regular job”).
Susan quickly found herself in a trap. There were just not enough hours in the day to get everything done. She worked hard and had high expectations of herself and other team members. Unfortunately, sometimes Susan's team members failed to deliver the right quality of work. When this happened, she tried to make up for that by re-doing the parts that weren't good enough. This approach allowed her to get some work done, but it just doesn't scale. She soon found herself exhausted!
Exhibit 5: Woodrow Wilson quote.
How do I borrow the brains of others?
To try to get out of the trap, Susan tried to get help from her team members. She told me the story about one time when she tried to delegate. Susan's team had just spent three intense months performing a major upgrade to a financial system. Her team worked crazy hours and delivered more than they had promised. It was a heroic journey for Susan and her team.
After the new system had been in production for a couple of months, Susan's bosses came to her asking for a report on the success of the upgrade. Susan went to one of her team members for help.
He agreed to help. He “helped” by emailing a copy of the new system's transaction log to her. Just the log. No analysis. No conclusion, just the raw data. Obviously, this didn't meet Susan's need. Worse yet, her team member thought he had done a good job. He either didn't understand what was needed, or lacked the skills to deliver what Susan and her bosses wanted. Susan wasn't able to borrow her team member's brain, and ended up writing the report herself. She asked me, “Do you see why I can't delegate to these people?”
How to Develop a New Mindset
In order to adopt a new approach to delegation, you'll need to first change your mindset.
The story that you tell yourself today is that the secret to your success has been your ability to deliver great work as an individual contributor. Your understanding of the technical issues has helped you understand the requirements, overcome challenges, make connections between systems and components, define problems, diagnose root causes, consider options, troubleshoot errors, and deliver great work product.
You need to stop looking at yourself as simply an individual contributor with extra duties. You need to intentionally lead your team members and delegate work to them.
There's a story about a man who approaches some hardworking bricklayers. He's fascinated by their work. He walks up to the first one and asks, “Say, can you tell me what you‘re doing?” Annoyed at the interruption, he turns and snaps, “I'm laying bricks! What does it look like I'm doing?”
Undeterred, he turns to the next man and asks the same question. The second man looks at him and answers, “I'm building a grand cathedral.”
In this example, you've been a GREAT bricklayer. Your walls are tall, strong, and straight, and now, the time has come for you to see yourself differently.
All of the skills you have developed and honed in your career are still relevant. Your personal contribution as a single worker has been the story of your success—and now, your story will develop further. All of the skills listed above still apply, but you'll need to begin applying them a little differently.
You're no longer a bricklayer
Marshall Goldsmith says, “What got you here won't get you there.” Your thinking—your story—about what makes you successful has to change. You're no longer just a bricklayer. The first step in successful delegation is for you to begin to see yourself differently.
In the past, your success has been measured by your personal performance:
- The number of bricks you laid;
- The quality of your work—the strength, height, and straightness of the wall; and
- The timeliness of the work—how fast you completed it.
See yourself differently—you're a general contractor, not a bricklayer
Now you are still in the business of getting walls built, but they are the means to the end. The end is the grand cathedral, and it's comprised of the walls and other pieces created and assembled by many and various craftsmen. Your job is to orchestrate the work. You're not successful if you merely deliver a great wall—you need to see to it that all the pieces come together and create something amazing.
At this point, you may object, saying, “I've already got more than a full-time job just keeping up with the work I've got. There's NO WAY I can take on more. There just are not enough hours in the day.” And you're absolutely right. You need to start handing off more and more of your work to others so that you have the time to work on acting as the general contractor of the cathedral.
As the general contractor, you may do some of the work yourself. At the core, you'll have subcontractors who will do much of the work on your behalf. Together you'll be creating that cathedral.
The 30% Solution
Once you've changed your mindset and you're looking for ways to delegate work to the team, you need a plan for how to make that happen. Let's take a look at one approach I call, “The 30% Solution.” In the following case study, we will walk through what it looks like to begin to delegate work to a project team member.
Exhibit 6: How to begin delegating work.
Using the 30% Solution, the project manager fully delegates 70% of the work to a team member. The other 30% is completed as a team effort between the project manager and the team member.
Phase 1
For the first 20% of the work, the project manager works side by side with the team member to ensure clarity of goal, direction, methods, communication, and more. Upon completion of the first 20%, the work is fully handed off to the team member.
Phase 2
For the next 70% of the work, the project manager is available to provide insights, support, and clear roadblocks—but is not directly involved with the tasks himself.
Phase 3
For the last 10% of the work, the project manager rejoins the team member to support him/her as they “land the plane” together. This delivers the needed project value with the right timing and quality level to deliver the needed project value.
This model:
- Allows for team members who are not yet fully trained to deliver work at the correct level. Because they are collaborating directly with the project manager, the project manager can help train and support the team member.
- Increases the project manager's productivity by freeing him up from direct, daily contact with 70% of the work required for deliverables.
- Supports quality of final deliverables by increasing contact between the worker and the project manager before the work is due to be delivered.
Case Study: “The 30% Solution” & Software Development
Background
Steve is the director overseeing a software development team in a large company. Steve got promoted to this role because he was a really effective developer. He understood what customers needed and made good decisions.
Things have been going well since Steve took over the team. His team has grown, and his area of responsibility has been growing, too. His “to do” list has gotten longer and longer. Steve has figured out that unless he finds a way to clear some things off his plate, he's not going to be able to keep up the pace.
Mitu is a team member on Steve's software development team. She has been a hands-on coder for years, and works well with customers and other team members. Steve wants to give her more responsibility.
Up to this point, Steve has focused on working with business customers to understand their needs; managing the process of getting estimates from the technical team members, planning release schedules, and communicating with customers.
Mitu has set herself apart from the other developers. In addition to designing and writing good code, she has already been coordinating tasks on her team. Recently she has been running the team meetings, and Steve has leaned on her to be an escalation point for technical problem solving and as a key troubleshooter. While she's been doing a good job and is already growing in her career, Mitu also wants to get promoted to Lead Developer. To make that happen, she knows she's going to have to stretch her skills even more.
Understanding The 30% Solution
As a part of her development plan this year, Steve wants Mitu to take on more responsibility for the “business” and “customer” parts of solution delivery, but he's not sure exactly how to hand it off to her. He heard about the “30% Solution” and wants to give it a try.
What can Steve hand off to Mitu? First, he looked at his task list. His big project right now is the launch of the new version of their analytics toolkit. Mitu isn't ready to run the whole thing.
Steve decides to ask her to take on managing the process of getting the release features through QA. This will require her to coordinate between development, product management, and QA.
Steve does a ton of that work “naturally” today. He doesn't have a specific documented process, and has never trained anyone on how he does it.
Getting Started
Steve started by “saying it out loud.” He knows that people need to hear it from you. He meets with Mitu and says:
“Mitu, I want you to start to oversee the process of getting the next release through QA. I'll work with you on this process, but I need you to be responsible for making it happen. I've been learning about an approach to this, called the 30% Solution.
On this project, I'll work side by side with you for about 30% of the work. At first, we'll do a lot together to help set direction, train you, and get you started. When we‘re about 20% of the way through, I'll hand it off to you to do on your own. I'll be a resource for you, but you'll take over and run with this for the next 70% of the project until we're almost to launch. Then, for the last 10% of the process, we'll work together again to finish the project.”
To get started, Steve invited Mitu to all of the meetings he attended related to the project, told all of the stakeholders that Mitu was going to have the lead, and asked her to take notes in the meetings and develop a list of action items after each meeting. Steve worked with Mitu to make sure that she had a good plan, and then he stepped out of the way to let her address any issues that came up.
You Did What?
For the first two weeks, everything ran smoothly. Mitu attended the meetings, came up with action plans, ran them by Steve, and got things done. It was taking longer than it would have if Steve had “just done the work” because Mitu and Steve were both in all the discussions, but it was a part of the process, and things were going according to plan.
As they had discussed, about two weeks into the process, Steve began to pull back and let Mitu handle the meetings, action plans, and follow ups.
It wasn't long before Steve started getting nervous about how Mitu was doing. He was keeping an eagle eye out for the “Product Management Status” Word document. Development uses this document to track open tickets and ticket status for discussion with Product Management. In fact, Steve had spent two hours with Mitu training her on how to pull the ticket info from the database, reformat it for Microsoft Word, and make sure that there were enough printed copies before the status meeting. He was shocked that she had not sent it out.
During their next one-on-one, Steve asked how the Product Management meeting had gone. “It was fine,” Mitu said. “But what about the Word document? I never got a copy of that. Did you forget to copy me?” Steve asked. “No. I decided not to do that anymore,” Mitu replied.
What?!?! Steve was shocked. A thousand thoughts ran through his mind. He thought to himself, “but…that's the tool we use with Product Management; that's how we track, prioritize, and schedule the work. You can't do the job without that document. It's fundamental to the process. I bet that Roger was really ticked off about that! How was his Product Management team supposed to keep up without that document? How did anyone know what was going on?”
Steve was getting REALLY nervous, and a little upset at this turn of events. Mitu was really screwing this up. Had he made a big mistake asking her to do this? Was it too soon? Was she really ready for this?
Steve paused, gathered his thoughts, and asked: “Uh. Ok. How did Roger respond when you told him you didn't have that document for the meeting?”
Yes, That's What I Did
Mitu explained: “Actually, I think he was pretty happy about it. We talked about how to make our meetings better, and that document was slowing us down. I decided we could just directly review the Jira tickets,” Mitu replied. “We were spending so much time copying information into the Word document, manually taking notes, and then transcribing them back into the tickets, that I figured it would be better for everyone if we just went straight to the source.”
“But how do you stay on track? How do you know which tickets to review? How do you make sure that nothing falls through the cracks?” Steve asked. He had spent months developing the Word document process and was sure that this new idea was probably a bad one.
Mitu replied, “I spent a couple of hours and built a Jira plugin that generates the ‘hot ticket’ report. It allows us to pull just the current tickets scheduled for the next release, and prioritizes them based on expected due date. Sure, it cost me some time to create the report, but I'll make it up in the time I save by not creating the Word doc and re-entering data after the meeting.”
Steve was stuck. He was uncomfortable, but he had to admit that her approach was at least as good as his. It's not that Mitu was wrong; it's that her approach was different.
Begrudgingly, Steve allowed, “Mitu, I'm worried that this change may make us miss something important. I'm letting you run with the ball here, but I want you to keep a close eye on this. Roger is really picky, and we can't afford to drop the ball on working with him.”
Mitu replied, “Steve, I think we're going to be fine. Roger is happy about it—our meeting was over 10 minutes early last week, and he said he liked working with me.”
The Last 10%
Over the next several weeks, Mitu reported that the Product Management meetings were going smoothly. Steve grabbed lunch with Roger to get the “real story.” Roger was happy with the progress and was getting excited about the new version launching.
As launch approached, Steve rejoined the meetings and sat back while Mitu did her job. He met with her, offered guidance, and allowed her to handle the issues the way she felt was best. They had a few intense moments, and some difficult conversations, but Steve had to admit that Mitu had come a long way, and many of her ideas were working just fine.
Case Study Summary
Following the 30% Solution, Steve provided guidance at the beginning for the first 20% of the project. He let Mitu take the lead for the largest part of the project, the next 70%, and then he worked with her at the end for the last 10%.
One of the challenges that Steve had to overcome was being willing to let go of “how” the work was done. Steve shared some of his concerns with Mitu, but ultimately, he let her make the call about how to do it. It was hard, but he did it.
And the best part? Steve was freed up to focus on working with Marketing, Sales, and Operations to help them be ready for the next release.
By having Mitu step up, Steve could focus on the most important work, leading to more sales and happier customers.
The 30% Solution really worked!
