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

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 t...

So What is this IPaaS Stuff, Anyway?

 In my last post , I discussed how no-code/low-code platforms fulfill rapid development of business applications - addressing the needs of the Citizen Developer (a Gartner term  first used around 2009).  I also commented on how this specific objective limits their ability to provide true integration capabilities, which require the flexibility to adapt to the myriad variations of infrastructure.  This is a concern because companies often have acquired legacy systems via M&A activity while simultaneously investing in new technology solutions, resulting in a mishmash of systems with multiple ways of accessing them. In this post, I'd like to examine how the needs of the latter group are met by describing some key capabilities that are "must-haves" for any company looking to execute on a digital transformation strategy.  In order to do this, let's define who the target user base is for such a technology platform. Disclaimer:   I work for MuleSoft (a division...

Application Development Done Right

In a previous article, entitled DevOps as the Ultimate Panacea? , I described how developing code without thinking about the current needs of the end user as well as the future needs once they've become accustomed to using your application ends up not only frustrating them but also can result in customer churn and ultimately lower revenues.  In this article, I'd like to describe something simple that I came across today that shows a definite degree of effort to do quite the opposite. Recently, we had a severe snowstorm, one with blizzard-like conditions, which is unheard of in central New Jersey.  Being responsible adults, my wife and I went to the grocery store to stock up on essentials (read:  chips, chocolate, etc.) in case we get stuck at home. As we were ringing up our order, the cashier mentioned to us that the store has a mobile application.  Since both of us are in technology oriented professions, we were skeptical about the need for a grocery store mob...