Empowerment.

One of the most over-used, warmed-over leadership terms uttered daily. Leaders high and low espouse their expertise in empowering teams to deliver. Some are very good at it, fostering high-performance teams who deliver great results. Others, though, only think they are good at it but frustrate teams with micromanagement, apathy, vagueness, and randomization. Most anyone who has been around the block has seen both good and bad empowerment examples. As for me, I’ve not only seen it, I’ve committed both the good and bad. It took me years to understand that empowerment isn’t just about delegating tasks to be performed. True empowerment is about entrusting individuals with problems to be solved and supporting them in the process. A high-performance empowered team owns problems or missions and is supported by a leader who provides clarity, gives guidance, and resolves only those issues the team can’t resolve on their own. To put some meat on this, I like to think of empowerment as systematic, with four critical steps needed to ensure its success. I call this intentional empowerment.

Step 1 – Define the problem to be solved and ownership
The first step in intentional empowerment is the clear articulation of a problem statement. The size of the problem doesn’t matter, it can be something that will take hours, days, or months to solve. What matters is a clear understanding of the problem statement, as well as ownership of the problem statement and the resulting solution.

Here is a good example:

• We need to reduce our invoice processing costs by 15% to align with mandated cuts across the organization. I would like you to take point on creation and execution of a plan to achieve the 15% cost-reduction goal.

And a bad one:

• Go develop process flows on our invoicing process so we can look for cost reductions.

While process flows may be a necessary step, you as the leader have delegated an errand to someone else and retained control of the problem. The person will run the errand, give you process flows, then await your next instruction.

Step 2 – Articulate the guiding principles
Articulating guiding principles is about policy, legal, regulatory, or other guidelines which the solution needs to adhere to. Note this is not about telling the problem owner how to do something, it’s about ensuring the problem owner knows the boundaries that he or she needs to abide by in solving the problem.

Some good examples of guiding principles:

• All invoices must be paid within ten days to ensure we get a 2% trade discount.
• Any personnel hire/fire recommendations must be first discussed with HR and kept strictly confidential
• Ensure the solution has the buy-in of the purchasing director.

And a couple of bad examples:

• Here is how you should go about solving the problem.
• Go talk to the purchasing director, interview her on what she thinks should be done, and tell me what she says.

Guiding principles aren’t about controlling how something gets done, they are about the problem owner knowing what latitude he or she has in solution definition. 

Step 3 – Ensure agreement on key dates
Knowing when something needs to be done and any key interim milestone dates enables the problem owner to figure out tasks and resourcing needs to hit the dates. It’s crucial here to get crisp on a specific date, not an “ASAP,” “immediately,” or “yesterday” date. It’s important for the leader to have his or her key dates thought out to ensure alignment with the problem owner. A good example:

• We need the plan done by April 15 in time for our annual review with the VP with subsequent implementation complete by fiscal year start of July 1.

And bad ones:

• I need it yesterday.
• I need it ASAP.

It may be that a problem needs to be resolved urgently; if that’s the case then stress the urgency to the problem owner but put a date on it. Don’t leave the when up to interpretation.

Step 4 – Establish the follow-up cadence
Key to intentional empowerment is an agreed-upon and timely follow-up cadence that both the leader and problem owner understand and agree is appropriate. When done well, the leader and problem owner stay aligned on execution and can fulfill project “asks” on a timely basis. It also minimizes surprises and frantic rework when expectations aren’t met. Just as importantly, though, is the leader staying in his or her lane by serving as a resource for the problem owner. An impatient or meddling leader can start micro-managing or dictating how something should be done. The problem owner turns into errand runner, with the leader hijacking problem ownership. Empowerment gone bad.

The cadence frequency should be appropriate to the problem and its due date, whether it be monthly, weekly, daily, hourly, or some other increment. As a leader it’s important to work on the frequency right-sizing with the problem owner; too infrequent can communicate disinterest, too frequent can communicate distrust. Here is an example for a project with a due date of one month:

• Schedule 15 minutes each Friday for both of us to go through status, issues, risks, and any help-wanted requests.

For the same project here are a couple of bad examples:

• Check in with me every day to tell me what you’ve done and what you’re going to do.
• I’m very busy, just let me know when it’s done.

There’s no one-size-fits-all follow-up cadence, what’s important is that the cadence exists, and both the leader and problem owner agree it’s appropriate. Again, too-infrequent follow-up communicates disinterest, while too-frequent follow-up communicates distrust.

I want to leave you with one last thought. Empowerment is a privilege, not a right. Those who are empowered have to earn and keep the trust of their manager, peers, and employees. Ensure when you are empowering someone to solve a problem that you are doing so because you trust him/her, and that if the trust is breached the willingness to empower diminishes. With that being said, take the time to understand intentional empowerment and use it to create high-performance teams that deliver value to your organization.

Since Microsoft Project's initial release in 1984 it has evolved  into an incredibly powerful and sophisticated project management tool.  One of those sophisticated features is calendars.  As one of my heroes  Spiderman says, "with great power comes great responsibility".  As a project manager, you can exploit some of the cool capabilities with Microsoft Project calendars, but beware, you could really tie your shorts up in a knot if you start getting too fancy with project calendars.  In addressing this topic, I want to start off by telling you what Microsoft Project help says about calendars then give you a few tips to help you avoid Project Manager hell when trying to develop a meaningful and realistic project schedule.