Skip to main content

Being a Good Leader

The Leader
A few weeks ago, I came across an article that described the 7 top qualities of a C-level executive.  And while I found the article to be a good read, I also recognized that there are key differences between a C-level executive and a "normal" manager.  This got me to thinking about the qualities that make up a good leader in general.

The archetype for this person is my father who used his lack of a High School education as motivation to push himself harder than anyone.  He did ultimately get his GED and an Associates Degree via correspondence courses, but it was his ascension to upper middle management during his 30 year career with the company now known as CenturyLink that I focused on.  His qualities as a leader earned him such admiration that his former staff - he retired over 10 years ago - still respect him today as though they were still working together.  Here are the things that I learned from him over the years of my life.

Communication is the key to everything.  I remember him telling me this when I watched him study during those correspondence courses.  He was learning vocabulary and composition / communication skills at the time and remarked that good communication is what separates you from everyone else.  In a business setting, this means outlining your expectations clearly in a way where it is possible for your staff to perform self evaluations on their own to assess their progress.

Transparency earns trust.  In any relationship, business or personal, trust is the foundation upon which everything else rests.  In business, however, the manager / staff relationship has to be founded on the trust that the manager represents the staff and the collective best interests of the manager's organization.  This means that transparency in all things must be maintained.  Ulterior motives and alternate agendas do nothing but sow seeds of discord when they are discovered.

Empathy earns loyalty.  There is an expression that says "truth without love is cruel; and love without truth is foolishness."  Applying this to a business context, it is not important to also earn the trust of your staff but also their loyalty because it is that loyalty that will inspire them to greater heights.  Ultimately, the action of explicitly acknowledging to them that they are people with real world concerns both at work and at home will result in their support of you even if they are unsure themselves of the end result of your actions as their leader.

Respect is earned.  It's obvious that you shouldn't ask your staff to do something that you aren't willing and able to do yourself.  But it's better still if you don't ask your staff to do something that you aren't already doing.  Tom Brownlee was a manager of mine for a number of years, and he was the strictest person I've ever worked for.  He was incredibly demanding, was not afraid to tell you to your face when he thought you made a mistake, and set the highest standard for quality in any sales organization of which I have been a part.  And while he rubbed many people the wrong way, those who stuck it out did so for one reason:  he held himself to an even higher standard than he did his staff, and he acknowledged when he made mistakes himself.

My father had a similar work ethic.  He knew that he didn't have a four year college degree like every one of his peers.  But instead of allowing that to discourage him as a seemingly impossible mountain, he strove to outdo every one of his peers.  And ultimately, he became the only engineer in the history of the company to ever earn a top rating of 1 on his annual evaluation.

Being a good leader, regardless of whether you agree with this list of traits, enables you to be an effective one as well because not only are you respected and trusted when things are going well, but you are respected, trusted, and your staff reaffirms their loyalty when things aren't going well also.

Popular posts from this blog

"Ni jiang yi yang de hua ma?"

Last week, I wrote about the necessity of having a clear message . Because this topic is so important I decided to follow-up with another entry on this general subject. This week we will approach it from another angle. (For the curious, the title says " Do you speak the same language? " in pinyin, which is a transliterated Mandarin Chinese.) Recently, a good friend of mine (who is Chinese, ironically) and I were playing pool. He had to bank the 8-ball in the pocket to win the game, and since it was an informal game and bank shots are my area of expertise, he asked me for advice. I told him, "you just need to strike the cue ball with medium speed so that it hits the 8-ball right in the middle." He didn't believe me so we marked the positions of the balls, and then he took his shot only to watch the 8-ball sail past the pocket. "A-ha!" he exclaimed. "I told you it wasn't that easy." But when we reset the positions and I made an attemp

It's Easier to Fail at DevOps than it is to Succeed

Slippery when wet Since the term DevOps was coined in Belgium back in 2009, it is impossible to avoid the term whether in discussions with colleagues or in professional trade magazines.  And during the years while this movement has gained momentum, many things have been written to describe what elements of a DevOps strategy are required for it to be successful. Yet in spite of this, there is an interesting data point worth noting: not many organizations feel there is a need for DevOps.  In a Gartner report entitled DevOps Adoption Survey Results (published in September 2015),  40%  of respondents said they had no plans to implement DevOps and 31% of respondents said they hadn't implemented it but planned to start in the 12 months after the survey was conducted. That left only 29% who had implemented DevOps in a pilot project or in production systems, which isn't a lot. "Maybe it's because there truly isn't a need for DevOps," you say.  While that

Is No/Low-Code the Key to IT Nirvana?

 Unless you've had your head in the sand for the past year or so, you've seen the phrases low-code  and no-code  bandied about quite frequently everywhere you look.  You've probably wondered if this is something new that's here to stay or just a "flash in the pan."  Although the terms have been in the fore of the IT trade publications recently, Low Code Development Platforms (LCDP) (and the corresponding No Code Development Platforms) have been in existence since 2011.  Their roots can be traced to the 90's with 4th generation programming languages and GUI-assisted programming paradigms, e.g. IBM VisualAge for Basic, which was discontinued in 1998. For those of you who aren't familiar with either, the premise is that these platforms allow someone to quickly build applications using a WYSIWYG interface and a "click and configure" paradigm to Isn't this the source code to Roblox? rapidly build full applications with little or no coding requ