Colin Powell's Lessons in Leadership - 1

General (Ret) Colin Powell is one of my personal heroes. A man who literally earned everything he has, knows how to make the hard decisions, and remains honorable and honest about those decisions. He is a rare breed that we do not commonly find in the world today (or ever). I came across these slides and wanted to share them with my readers (however many or few their might be), as well as provide any comments I may have from my own experience. Since I don’t see a copyright on them, I hope that I can share them without causing trouble.I will post one slide each Friday until they are all posted. Then I will post a link to the entire set on the last Friday. If you try real hard, you can probably find the slides yourself and jump ahead... but where's the fun in that?!

Lesson 1: Being Responsible Sometimes Means Pissing People Off

I have two sons, so sometimes I read this one as “You need to be their DAD, not their friend.” From a leadership perspective the same is true. You need to be their Leader, not their friend. It’s amazing to me how many people avoid “unpleasant” responsibilities because they don’t want to offend somebody, or are afraid of how the other person will react. In some cases it is simply making a request (my wife often tells me that the worst a person can tell you in this case is “No,” which doesn’t leave you any worse off than if you hadn’t asked in the first place). However, there are many times as a leader that you may need to do something more than say no. 

As a Leader, your decisions will impact people, and sometimes for the good of the unit, company, even sometimes the person, you have to do things that will piss them off. If you are uncomfortable doing that, good. Nobody should like to piss people off. If you are incapable of doing it, then get out of the leadership role. There are plenty of well paying jobs that do not require you to make these types of decisions. If you can make the decisions, stop worrying about the feelings of others and make the decision.

Now, don't take this to mean that you should discount other's feelings. If you discount them totally, you will end up with a large group of people waiting for (and sometimes helping) you to fail. But, if you make a decision, and explain why the decision was made, at least people will know the reasoning, and most people will accept it. The ones who don't are situations you need to address as a leader in the first place (which can lead some people into another moment of avoidance). 

As a final note, I want to point out the last sentence in the slide. In my short career, I see this constantly. Everybody has their "go to" person. Somebody who is the problem solver, the (as my wife calls it) "Staples Easy Button." They are the creative people who take an assignment, run with it, and accomplish things. These people deserve to be recognized and given opportunities to advance. However, what typically happens is that these people become "mission critical" and stay in the position that makes their manager (notice I didn't call these people LEADERS) look good. The people that are less able, less "mission critical" get the career advancement opportunities because they are "available" for the opportunity. I had a boss in the Army who did that to at least 4 people (that I am aware of, yet another future blog entry). Because of that behavior, because the best and brightest are kept overwhelmed and in a box, they will be the first to leave. If you find yourself in a position with a "mission critical" person, you should do everything you can to train somebody else to take the strain, and reward that mission critical person for his/her impact. If you don't they will move on from a manager who can't to a leader who can.

Wacky Wednesday

Since we are talking about Communication this week, I thought this Dilbert was appropriate:

Too often we try to communicate a concept without giving a person enough details or the proper frame of reference. The image is so clear to you, that you neglect to think that it might not be clear to others. Out of all forms of communication, EMAIL is the most notorious for this. Think about it, in ever other major form of communication (I am not counting fax machines as a major form of communication) has some type of feedback to let you know if the message is understood. Even text and instant messages often get a reply, even if it is only a "?". 

We often find ourselves reading emails that are unclear, not specific enough, or assume a frame of reference that we do not have. Worse, you've probably written emails with the same assumptions. The next time you start pounding away at your keyboard, check to make sure that everyone on the To, CC and BCC line really need to be there, and that they have the appropriate background/frame of reference to understand what you are trying to convey. The last thing you need as a leader is an employee that will "act randomly and hope for the best:.

Communication - The Purchase Order Calculator

When you are a team of 1 working on a projects, most would assume that communication isn't necessary. I would argue differently. Even though I was a team of 1 on the Purchase Order Calculator (thread started last week here), I still needed to communicate with the "stakeholders" of the Project. A stakeholder is ANYONE who COULD be impacted by your project. In my case it was not just the Project Management Group, but also the Order Management group that created the POs. I think many a leader has learned to their chagrin that if you don't talk with stakeholders, your project will fail.

Now in my particular case, since I was working on this during my "down-time" I talked with the workers rather than the managers. I assumed (for once rightly) that it would be better to present a "finished" product to the managers rather than present a concept that would be rejected out of hand. I talked with a sample of 5 PMs and 5 OMs (roughly 1/4 the PMs and 1/3 the OMs) about how each of them created, tracked and validated the internal Purchase Orders. I also asked if they had any improvements they wanted to see. More often than not, this became a gripe session; but I still learned a lot about formats that would be best received, as well as the biggest questions and trouble areas. This new information  allowed me to refine the concept of the calculator, as well as design it in a way that people would actually use.

Now, although Communication is the 2nd C in C4, don't think that Communication is done after the initial interview. Communication (like all the other Cs) permeates throughout the leadership cycle. You need to constantly communicate. I would make a prototype, and give it to some "testers" who would comment. Those comments brought about tweaks to layout, programming (yes, I consider If/Then Functions in Excel programming!), and the initial presentations to the managers for use. Without Communication, this idea would have stayed on my computer, never seeing the light of day.

Over time, those 10 people became my beta-testers. Now, another lesson about communication: BE CAREFUL WHO YOU SHARE WITH. In this case, credit for my design wasn't stolen (although it was a very real concern). Something else happened. Something shocking. One of my beta-testers used the Calculator for about 2 days, then ran to her manager praising the thing at the top of her lungs. It still had some bugs to work out, and I wasn't ready to present it to the managers, but her enthusiasm basically blasted the "veil of secrecy" away from my project. The game was on now.

Photo credit: http://isobe.typepad.com/sketchpad/2004/05/post_1.html

I received a call at my desk from the manager in question, who asked me to stop by her office. When I got upstairs, I was shocked to see my Excel template open on her computer. Thankfully, before I could go into "panic" mode, she simply asked me to explain the calculator. Over the next hour, I found my caution evaporating and my enthusiasm building. That hour became a "practice session" for the pitch to other managers on my Calculator.  After that hour, the manager sent the spreadsheet to her entire team, with directions to use it for the next week and reply with any concerns or bugs. My beta-test went from 10 people to 30!

Thankfully, the calculator, while buggy, was usable. The most common plants for internal Purchase Orders were already in place and stress-tested. The bugs were more to do with small facilities without hard and fast rules for Purchase Order Values (this will be covered in the Complete section of this series). I did learn some valuable ways to tweak the Calculator so that it was more user friendly, and I refined my sales pitch. I also developed a core group of users who were enthusiastic for the amount of time the Calculator saved them. Overall a win-win!

So the next time you have a pet-project and you are the only one "working" on it, remember to think about "who" it impacts. Communication with them can bring about rapid change and progress. Failing to Communicate with them can cause project failure and wasted resources.

Next week: Command!

Wacky Thursday? - The Original Concept for the Camoflauge Pattern from the Army Becomes Clear

I was still in the Army when the new "Digitized" BDUs (That's Battle Dress Uniform for you civvies) came out. Supposedly it would blend well into jungle, desert, woodland, and urban environments. Most of us had our doubts but HERE is the proof:

photo credit: unknown, received via email

Urban ... maybe... Grandma's old couch DEFINITELY!

An apology for my followers about missing yesterday. Real life dropped on me like a ton of bricks! Of course, a leader keeps his commitments, so this is me playing catch-up. Enjoy!

Conceive - Purchase Order Calculator

Recently an attendee of one of my presentations asked me about the 4 C's. After answering her question, I realized that I should probably take something through the 4 Cs and explain how each one came about. I decided to use an example from my time as a Project Manager. I will talk about each stage and how I implemented the upgrade (and how it went a lot further than I expected).

As a Project Manager, I ran into a particular situation that seemed to be taking a lot of time from my days and weeks. At the time, the PM reviewed each Sales Order (SO) that initiated the demand for the projects. After the SOs are confirmed, we reviewed the Purchase Orders sent to the individual manufacturing plants. Each plant has a different rule for the value of that Purchase Order. When you are talking about 33 different facilities, that is a lot of rules to remember. Now the unfortunate thing was that the rules also changed based on which business group was releasing the PO and what country was the location of the issuer and the receiver. The end result was a list of rules and a giant table that PMs, Order Managers, and the various facilities all needed to abide by. Now, here is the fun part... the system did not automate the values, so each PO was determined by an actual physical calculator on somebody's desk, or some other "human" factor.

After about 4 months on the job, I realized how much time I was spent determining PO values, confirming PO values, and arguing with the individual plants about those values and how that value was correct because of such and such rule. On average I was spending roughly 4-5 hours a week in conversations related one way or another to this topic. Unfortunately, I realized that most of my fellow PMs were experiencing the same problem.

This was the identification of an improvement. I saw a need. We could save hours and hours of emails, phone calls, and fingers to keyboards and calculators if I could find a way to "automate" the process. That is only the beginning of Conceive. I knew there was a need and determined a potential way to fill it. However this isn't the full step of Conceive.

The FULL steps included a list of resources (I tried to recruit help, but, as is typical with most projects that don't come from above, everyone was "busy"), an evaluation of what those resources could contribute, a schedule to move forward, and most importantly, an end goal to work towards. In this case I knew my talents, which made parts 1 and 2 easy. I am not a computer programmer. Anyone reading this who knows SQL will probably cringe, but I decided that I was Microsoft Excel savvy enough to build logic statements to determine the criteria for which rule to take effect.

I couldn't work on this during company time, instead I needed to do this at home. I didn't want to take away from time with my new born son, so that meant after he went to bed. I would work on this from 8-10 PM on weeknights (and try to slide in weekends). But that wasn't specific enough. I picked Thursdays as the day of the week that I would work on this (Monday being Heroes night; Tuesday was Toastmaster prep night; Wednesday was Toastmaster presentation or PMI night, and Friday was quality time with the wife!). What about the remainder of the timetable? I decided that 3 months is long enough to create an Excel spreadsheet and present it to my boss (who, by the way, didn't know I was working on this). The end goal for this project was a spreadsheet that anyone could use to determine PO values regardless of which production facility the PO went to. Calculation time would drop dramatically because only contract data would be needed. And, if the spreadsheet was viable, it would cut the arguments down as well, since the formulas were built in! Ambitious, but I thought completely doable. My solution was Conceived. 

Next week, I'll talk about how I Communicated my plan to my coworkers, the order processing group, and my boss; not to mention my lovely wife. In 2 weeks, I'll discuss the Command portion, with the actual execution, test cases, and adoption. Finally, Closing, with Lessons Learned and a rather startling discovery. I hope you stick with me!