Five Qualities of People-Focused Leaders

When you’re in a relationship, if you are aware of a problem, it’s your responsibility to make a concerted effort to make a positive change. - John Maxwell

I was reading Be a People Person: Effective Leadership Through Effective Relationships. by John Maxwell over the weekend. The "big idea" of Be a People Person centers around getting the most out of those around you in work, family, and social life, by improving your interpersonal relationships.

At the end of the day, the effort of a single person (you) doesn't scale well. To achieve remarkable results, you must rely on those around you. Unfortunately, people don't work effectively together by default. As a result, a large chunk of your effort as a leader should be spent on relationships in order to achieve the results you're looking for.

According to Maxwell, there are five qualities leaders possess who excel at building relationships with those around them:

  1. Encourage others - In short, you don't build great relationships with those who have a negative attitude towards you or your accomplishments. Encouraging those around you will not only build trust, but it will give them the confidence they need to succeed when times get tough.
  2. Appreciate others - Humans crave appreciation. Recognizing the importance of those around you and communicating their value to the team will pay huge dividends in the future. Appreciating others can take the form of giving credit for suggestions, correcting grievances, providing encouragement, and asking for the opinion of others.
  3. Forgive others - When we look back at mistakes we made in the past, we typically view our actions through the filter of intent. After all, we didn't mean to criticize so harshly. However, when we look at the actions of others, we judge through behavior. This allows us to easily jump to the conclusion that the negative actions of others were somehow done on purpose. However, this is rarely the case. Giving those around you the benefit of the doubt when something doesn't go as planned will help you focus on what's important and not waste time/energy fighting over things that don't matter.
  4. Listen to others - People want to be heard. If you have to make a tough decision, especially one that some of those around you disagree with, it's important to ensure everyone has an opportunity to voice their point-of-view before moving on. It's much easier to get buy-in from your team after everyone has been heard, regardless if they fully agree or not.
  5. Understand others - Peter Drucker says "60 percent of all management problems are a result of faulty communications." Taking the time to understand those around you will help avoid feelings of disappointment and resentment when navigating tense situations.

These five areas serve as the foundation for leading others. Success here can turn good leaders into great leaders through bringing out the best in the people on your team.

Maybe You Shouldn’t Schedule That Meeting

I read an interesting article on HBR last week outlining a framework for deciding whether or not to schedule a meeting. The quality of articles like this tend to vary anywhere between exceptionally helpful to common sense to a complete waste of time. The thing that stood out to me the most about HBRs article was the author outlined a framework for how to handle communication outside of meetings. This is an effective method that, if followed, should still result in the same level of communication (or better), but keeps everyone’s time from being wasted.

Meeting decision Tree

There is a ton of good information here, and I don’t want to simply re-hash what is in the article, so I will include some color commentary here and you should go check out the full article right after reading this post.

  • Schedule time to think/work - this is something we simply don’t do enough of as part of our busy workdays. Blocking off time on your calendar to tackle something specific is an effective way to make sure you are working on what’s important. It also ensures you aren’t distracted trying to accomplish the same work as part of a different meeting. Don’t have time on your calendar this week? Try scheduling some time in a couple of weeks and be pleasantly surprised when you “find” some time later on - your future self will thank you.
  • Leverage asynchronous communication - Just because you have something important to say, and have a few minutes to say it, doesn’t mean you need to call a meeting. After all, others may be busy trying to get work done, don’t bug them if you don’t have to. Instead, use IM or email or text to start the dialog and let your colleagues respond on their own time.
  • You probably don’t need to have a meeting - sometimes you do, most of the time you don’t. Are there ways to get the same level of communication across (or better) without requiring everyone to be in the same place at the same time?
  • Prepare - if you do end up scheduling that meeting, be sure to prepare. Put an effective agenda, schedule it for half to two-thirds of the time you think you will need, and manage the meeting size to reduce complexity.

Taking some up-front time to decide whether or not to hold a meeting can pay huge dividends in the future. If you can avoid one meeting per week 80% of the year, you can save a full week of waste. Imagine what you could accomplish with an extra week each year to focus on your goals.

Image Source - HBR

The New DevOps

My first five years as a software engineer, I worked primarily with a particular programming language. I had some responsibilities around testing and deployment scripts, but mostly I just worked with code and code-related activities. The following five years have been much different - there are entire projects that would have gone undelivered if I wasn't able to provide support in some area of Operations - networking, databases, operating systems, etc.

The development landscape has changed over the past several years. The lone-gunman programmer going off in a corner for months to deliver functionality has been replaced by development teams delivering business value every few weeks.

A similar shift has recently occurred in the area of Operations. Developers used to be responsible only for writing and (hopefully) testing their code. Infrastructure, networking, operating systems, RAM, CPU, power, and similar topics were someone else's problem.

Today, the landscape has again shifted to a more collaborative model merging development and operations (DevOps). Developers need to know much more about the operational components of their software - especially around network programming, services development, and continuous deployment. Likewise, the developer's IT counterpart needs to know much more about development - especially around infrastructure automation (Chef/Puppet), automated testing, and continuous deployment - I recently read a resume for an operations candidate that listed Ruby as one of the core skills.

As time progresses, the lines between developers and operations specialists will continue to blur, resulting in an ever increasing need for collaboration and communication between groups.

DevOps Infographic

Source - AppDynamics