What makes a good leader? I’ve given this much thought during the years I’ve been managing. I don’t believe any person in a leadership role sets out to be a bad leader – and bad leaders, unfortunately, usually think they’re good leaders.

What exactly does “leader” mean? I looked it up and one definition is “the person who leads or commands a group, organization, or country.”* It also means “a short strip of nonfunctioning material at each end of a reel of film or recording tape for connections to a spool.” *

While some may think of their current leader as bearing a great deal of resemblance to a nonfunctioning material, I’m going with the first definition of leadership and assume we’re talking about “the action of leading a group of people or an organization.” I also looked up the word management and here’s the definition I found: “the process of dealing with or controlling things or groups of people.”*

So, in looking at these definitions, I do manage people, but I also lead people. Leading is different from managing because as a leader, my intention is to inspire, motivate and provoke a desire for excellence from a large group of people, some of whom I will never meet.

You can’t control everything.

 

It’s true, I do manage my direct staff, and managing includes controlling things like budgets, but I can’t control everything. I have to depend on my leadership skills to inspire the organization to reach its goals and do some of the work of controlling things.

For me, a good leader understands he can’t control everything in the organization; he has to trust the people working for him. To achieve organizational goals, a leader needs to motivate and inspire their teams. To encourage innovation, a good leader knows he has to trust the people working for him to be creative and to think of new approaches for products, issues, or problems.

In one group I led, we had software quality issues. Not minor ones either. Some of the quality issues were because management wanted to hit certain deadlines and corners were cut. In other cases, it was bad development practices. So each vice-president had a goal for their organizations to decrease the backlog of defects as a starting place for addressing product quality.

We all decided on a certain percentage to hit and then told the teams to fix all of the high priority defects to hit that percentage. Things were going great! Most every team was on track to hit that percentage. We were slapping ourselves on the back in congratulating each other in hitting our goal.

But then I met with a developer. You see, I often do skip-level meetings with staff . These skip-level meetings often begin with some discussion on how things are going and general chit chat, but sometimes someone will say something quite stunning.

This developer, after about ten minutes of the general chit chat, paused, looked me in the eye and asked, “Why is this goal in fixing defects focused only on the high priority defects? Wouldn’t a better approach be to determine where all the defects are in the code and then tackle the code that seems so problematic?”

I was stunned. I looked at her before replying because I was thinking, duh, should have thought of that! We did meet that year’s goal of fixing a percentage of high priority defects, but the next year? We did exactly as she recommended. And the team found there were a couple of areas in the code base that needed to be reworked or refactored thereby resolving most of the software quality issues.

I learned from this experience that as a leader, I shouldn’t try to control what everyone does – and I don’t want to control every single thing. That’s not my job. My job is to trust my employees to hear what I think is an issue or problem. Then I listen to what they suggest before I make decrees. The results are often far better than I expect.

*New Oxford American Dictionary