I’m uncomfortable with the manager vs. leader dichotomy that’s bandied about lately.

Most of the time, the conversation is reduced to a sound bite: “Managers do things right, leaders to the right thing” (from a Warren Bennis quote).

Cute, but not helpful.

There is no single definition of management or leadership. How you define either term depends on your view of human nature and motivation.

Some people would define management as the process of dealing with or controlling things or people. On the other hand, Drucker would say the two central tasks of management are helping workers to achieve and moving capital from less to more productive areas.

When we talk about leaders, are we talking about charismatic leaders who gather followers to support them in implementing their own vision? Or are we talking about people who help people find their own power and creativity?

How management and leadership is practiced depends on the predominant beliefs of the organization and the mental model and skills of individuals. I believe that leadership doesn’t exist only in a role. It’s in taking action that make it possible for people to bring their best thinking and creativity to bear in solving problems and creating value. And frankly, I don’t see the title (or role) of manager going away any time soon. For one thing, there are legal and financial implications of doing away with the role.

Rather than denigrating the role (and by implication the people in that role) I would find it more useful to talk about what sort of support teams need, what skills are needed to provide that support and then design roles around that.

Maybe we can start a different conversation.

Here’s one starting point to think about the skills that people in management roles and leaders at all levels need (from Welter and Egmon):

Eight Essential Skills of a Prepared Mind:

• Observing
• Reasoning
• Imagining
• Challenging
• Deciding
• Learning
• Enabling
• Reflecting

I add:

• Self-awareness
• Self-management
• Ability to see systems
• Interpersonal skills

What sort of support does your team need?

What skills and attitudes will enable that support?

What might that role look like?

What does the organization as a whole need from that role?

I often work with groups who know where they want to go, have some good ideas on how to get there, but they are blocked.

When I ask why they can’t achieve the results they envision, they tell me things like:

–We lack resources.

–We lack funding.

–There’s a lack of organizational support.

Listing all the “lacks” almost never helps groups move toward their goal. All you can do when you have “lack of” is “get some.”

Instead of listingwhat you don’t have, describe what is – the attitudes, behaviors, structures, processes, etc that exist and are blocking you from achieving what you want.

Here’s a list of words I use to stimulate thinking about “what is” rather than what’s missing.

Outdated

Fragmented

Overlapping

Uncoordinated

Unrealistic

Reluctant

Disjointed

Confusing

Excessive

Unbalanced

Conflicting

Unclear

Restricted

Neglected

Obsolete

Pervasive

Misused

Extensive.

“Lack of funds” might become “Unrealistic funding for the current project”

“Lack of organizational support” might become “Conflicting priorities,” or “Overlapping sphere of control.”

Working through unrealistic funding for the current project, conflicting priorities and overlapping spheres of control aren’t a piece of cake to deal with. But it’s easier than trying to get some funding or whip up some organizational support.

“There is nothing either good or bad, but thinking makes it so.”

William Shakespeare’s Hamlet, Prince of Denmark, Act II, Scene 2

Johanna Rothman’s recent post talks about what happens when managers ignore or suppress data.

Trouble can’t hide when information is public. Trouble is, some managers, such as the one described in Johanna’s post, are unable or unwilling to “see” the current state, or let others see it.

Why? I have some theories:

–The manager may have deeply ingrained internal rules about failure or success that act against acknowledging the current state: Rules like “I must always meet others’ expectations,” “I must always deliver on my promises,” “I must never fail,” are powerful, influencers of behavior. We’ve all got them, we just bump into them in different ways.

–The organizational culture may cause people to suppress “bad news.” People in organizations that shoot the messenger often sugar-coat and suppress information about the current state. “Shooters” deprive themselves of the very information that would help them succeed, or at least mitigate disaster. Managers of the shoot-the-messenger school seem to be fond of phrases like “Failure is not an option!” My little internal metric is that the likelihood of failure is directly proportional to the prevalence of this phrase (and it’s close cousins).

–I’ve noticed that people with high self-esteem are more able to accept deviation from the desired state as information… neither bad nor good, that will help them take appropriate action. And I’ve seen managers with low self-esteem who were quite unable to admit that things weren’t going well. My theory is that people need a good bit of self-esteem to admit problems or mistakes.

–Some managers seem to know, on some level, that things aren’t going well, but they don’t know what to do about it. This not-knowing-what-to-do seems to paralyze some managers. (Managers are supposed to know how to do everything, right?) Rather than admit they don’t know what to do and ask for help, they let the situation continue spin out of control until it’s too late, or at least very difficult to take corrective action.

The common thread seems to be that managers who suppress “bad news” or appear oblivious to “bad news” are protecting themselves in some way.

On the other hand, I’ve met some manager who were masters at declaring victory in any situation, marketing up, and moving on before the consequences come home to roost.

I interviewed one project manager who left a project for another job six weeks before his project crashed and died. When I talked to him he said, with a straight face, “I don’t know what happened. That project was on track when I left, at most a week behind. How did they manage to ruin it in six weeks?”

I find these managers particularly puzzling.

On the subject of keeping project information public and avoiding the suppression mess, the participants on the AYE Conference wiki talk about Information Radiators and Public Project Progress Posters.

Yesterday I was re-reading The Myth of Fungible Resources in Slack by Tom DeMarco.

Here’s the definition of fungible that appears in the book (p.13):

Fun.gi.ble ….(especially of goods) being of such nature or kind as to be freely exchangeable or replaceable, in whole or in part, for another of like nature or kind.

Viewing people as fungible is the thinking that led to the staffing policies practiced at a multi-national company I once worked with:

All employees in IT or related functions were required to fill in a skills inventory. The skills inventory listed computer language skills (COBOL, C, C++, SQL, etc) and functional skills like requirements analysis, data modeling, data base design and project management. And it had a space to list level of proficiency, as evidenced by years of experience.

The global (everything was global at this company) skills inventory database was used to match employees all over the world to projects. A project manager anywhere in the world would fill out a form listing the skills needed on a project. A program would search through the database and produce a list of people who had the required skills and were available. Those people would be “deployed” as virtual team members to projects around the world! (Sounds so scientific, doesn’t it?)

This scheme was intended to replace the process of internal hiring, which involved having humans apply for internal openings and having humans review applications, interview and select candidates, saving money and making efficient use of resources!

There are just a few problems with this sort of program (and the thinking behind it):

–It doesn’t take non-technical skills and characteristics into account. What about traits like attention to detail, perseverance, able to see the big picture, encourages collaboration, works well with others? Personal characteristics and traits are just as important to the make up of a team as technical skills.

–It doesn’t account for domain knowledge. Building an inventory tracking system in C++ is not the same as building a Monte Carlo simulation in C++. The time to learn the domain would certainly cancel out the “efficiency” of eliminating the messy, human application and selection process.

–It completely ignores the need for challenge and growth. What if someone has been programming in COBOL for years and is aching for a change or a new challenge? Deny people who want growth the chance to achieve it, and they’ll usually move on.

Well, the Skills Inventory Database didn’t work quite as planned. It was quitely dropped, but not until the company had spent hundreds of thousands of dollars and made a good sized dent in the store of employee goodwill.

This is an example in the large. People fall for the myth of fungible resources when job descriptions list only technical skills, resumes are scanned for languages, tools, and technical skills and hiring manager ignore the candidate’s fit with the team and the culture.

But that’s another story.