Good Communicators are Good Listeners

A couple of weeks back I wrote how great developers have skills beyond syntax and design patterns. One of those key skills is communication.

Communication is a two-way operation, and the art of listening is oft overlooked, so I thought I'd offer some notes on the subject here. Specifically, what is commonly known as "active listening".

There is a difference between simply hearing someone’s words and engaging & understanding what someone is saying. If we want to be an active listener, it isn't enough to just hear what someone is saying. Active listening means i) we are focused on what is being said, and ii) we are open to the speaker's point of view.

For the first part, paying attention, we should be listening and trying to understand what this means. There are different means of doing this, which suit different people. For me, I do this better by taking notes (plus, writing down what people say makes them feel heard and important!) and by using follow-up statements like:

• Can I try to repeat back what you said, in my own words?...
• So, another way of saying that is ..... Is that correct?

Each of these makes sure we understood the person's point of view and gives them confidence that we are doing so.

The second part of active listening is being receptive to other peoples' thoughts and ideas. Sometimes this can be really difficult for developers, or other smart people, because many times they are 5 steps ahead of everyone else! However, interrupting or assuming what someone else is going to say can hinder us from hearing new ideas.

It is very important to make people feel heard (not just listening to their words, but understanding their points).  To be more receptive to others here are some tips:

Don't interrupt.  This one can be hard, when we already know the answer to something, or have thought through the solution or path already. However, allowing people to say their thoughts shows respect and consideration for others.

Don't assume what they are going to say. We might be right, but we could also be wrong, and either way it prevents the other person from voicing their ideas. Problem solving, brainstorming, and planning are all things that can be better done collaboratively, and that means each person should have a chance to contribute.

Do ask clarifying questions. Try to understand the "why" behind what they are suggesting; even if the "how" is wrong, their motivations may be sound. Getting to the root of things by asking questions makes the other people feel heard out, ensures the roots of issues get addressed, and can lead to more productive conversations.

Acknowledge their view as important. They probably wouldn't have said anything if it didn't mean something to them. Therefore acknowledging their point, or motivation behind their point, makes the other person feel recognised and their concerns addressed. A simple statement like "that is a good thing to consider" or "thanks for bringing that up, we should definitely note it" is all that is needed; even if you plan to refute that view or disagree with it.

Wait for their response. If we ask someone a question show that we want to hear the answer by waiting for him or her to respond. Some people (especially technical folks) tend to like to think things through before they verbalise them. Other people are more comfortable when they are talking. If you fall into the latter camp, make sure that if you are talking to someone who likes to think through their reply, that you don’t keep talking and wait for their answer. Ask the question, pause and wait.

Notice their body language. Not all communication is said out loud, so take a few moments and try to observe how the person is reacting to what is transpiring. Are they guarded? Visibly upset or shaken? Are they excited and happy, nodding along to the statements? These are all clues that can help us understand what is really going on under the covers. Learning to pay attention to these can help us change our tone, or adjust our approach.

Listening (and contemplation) is such an important element of communication. We should always remember that we have two ears yet only one mouth; we should use them in proportion!

Great Developers Communicate!

There are so many skills that make a difference between a good developer (someone who knows their syntax and has a bagful of good design patterns) and a great developer. Many of those differentiating skills are related to communication.

I wrote about good communication skills nearly six years ago, so it's probably about time to revisit the subject!

Few if any of us work alone. The vast majority of us work as a team. Communication within the team is a necessity, not an option. As a developer, good communication will ensure you deliver the right thing and gain recognition for your abilities; as a manager, good communication is important if you and your team are to deliver what the business needs when the business needs it so that they can get maximum business benefit.

Many developers like working independently and are proud of the autonomy they may be given. But the paradox here is that the autonomy and independence can lead to a lack of recognition of their abilities. Many of us have worked damn hard only to see the boss give plaudits to somebody who may have contributed much less to the collective. Why does this happen, and how can we avoid it?

Surely there must be some hard numbers that will make it clear who's contributing the most to the team. Well, in my experience, traditional metrics such as lines of code, bugs closed and features added all have drawbacks in the reality of day-to-day software development, e.g. are two small features more valuable than one larger feature? And clearly, softer activities such as writing-for-maintainability and helping/coaching others have no reliable metrics for comparison. So, if there are no reliable metrics, how do you get noticed?

I think it comes down to trust. When a manager gives autonomy and independence to team members they are trusting them to complete the assigned task, make wise and strategic decisions along the way, and pro-actively communicate problems long before the become a problem. For someone to invest their trust in us, we have to show that we are in fact a good investment. We might ask ourself:

Does my boss trust me?
Do my team-mates and peers trust me?
Have I done a good job to earn their trust?
How would my peers describe me to someone else?
How influential am I within the organisation?

As a team member, we want to be judged by our contributions, and we want autonomy and the ability to own substantial things. As a manager, we want to give recognition and praise to the people who deserve it, but we don’t want to micromanage and spend our days being Big Brother. So there's an implicit contract: I will give you autonomy and independence, but it is your responsibility to share status and information with me.

For example, a team member once told me he had worked hard and really gave it his best, but from my viewpoint his progress wasn't up to the same level of his team-mates. When he was leaving the company he told me all the things he had done – and I asked him "Why didn't you share this with me before?" You see, I would have advised him to spend his time elsewhere on priorities that were more important to the business. He responded with "I thought you would know." Don't make that same mistake.

And so my conclusion in all of this is: if you want autonomy, and the ability to own and control your own domain and projects – it is your job to push information and build trust with your team members.

In other words, you need to learn and do the following:

Follow through. Do what you say and consistently deliver on your commitments.

Pro-actively communicate when a task takes you longer than you thought, and why.

Improve your communication skills. In order for others to hear you, sometimes you have to hone the way you deliver your message.

Volunteer information and make an effort to explain vague or hard to understand ideas and concepts. Make an effort to share the details of your decisions and diversions. This is also important when you make mistakes – letting others know before they figure out on their own will show ownership of the situation and can prevent misunderstandings later.

Be forthright and authentic with your feelings. Even when you may hold a contrary opinion communicate your thoughts (respectfully and with tact).

Don’t talk behind the backs of others. It is very difficult to build trust if someone knows that you will say something negative about your boss, the company leadership, or another team-member.

Be objective and neutral in difficult situations. Learn how to be calm under pressure and act as a diplomat resolving conflicts instead of causing them.

Show consistency in your behaviour. Not just in follow-through but by eliminating any double standards that may exist.

Learn to trust them. This is one of the hardest ones, but trust is a two-way street. Giving others the benefit of the doubt and learning how to work with them is essential to a strong mutual working relationship.

In turn, hopefully, you have a good manager that will be able to ask you good questions and take the time to understand your contributions. And if that is not your situation, then make sure you are sharing information with those around you; such as your peers, your boss, and other stakeholders.

Good leadership is keeping everyone on the same page, and if you want independence it is your responsibility to make sure people know what you are contributing.

I don't claim to come close to following my own advice in all situations, but I do keep reminding myself of what I believe is the right route to trust and autonomy. What is your route?

NOTE: Tips to Avoid the Bus

Back in 2011 I wrote about the Bus Factor, i.e. the minimum number of people on your project (or in your support team) whose loss would cause serious issues for your project/support team. The name of this factor derives from the possibility of one or more team members getting hit by a bus. An alternative (less tragic) name - highlighted by Angela Hall at the time - is "lottery factor", i.e. we assume that one or more people got a big win on the lottery and immediately left work, never to return. Either way, it's a serious factor and must be managed.

At the time, I offered a number of techniques to help increase your team's bus factor (a good thing). Here are a few more that I use, all focused on the greater sharing of knowledge. If you ingrain the techniques of active and deliberate knowledge sharing into your team members then you need worry less about your bus factor, but don't completely take your eye off the ball - remember to manage it.

Push-Based Knowledge Sharing. The person who holds the knowledge about something asks a person who does not know about it to join them to learn about it. They thereby PUSH the information towards the other person.

Pull-Based Knowledge Sharing. The person who does not have knowledge about something asks another person who knows about it to teach them about it in some way. In this way, they establish a PULL of the information from the other person.

Knowledge-Share Handshaking. Having only a single direction knowledge sharing culture, i.e. only pull or only push, is not the most effective culture. There has to be a knowledge handshake for knowledge to freely flow through. Encompassed within handshaking is the idea of pairing. One of the best ways to remove bus factors, is by pairing. Pairing is an act of implicit learning where knowledge is constantly back and forth. On the other hand, if a person asks a question “How did you do that?” then that is an act of explicit learning.

Pairing is hard to achieve in organisations where pairing was never a “thing” people do. If you cannot get enough people to pair, or the bus factor is happening when a person from a different team knows something that your team replies on, it’s time to start encouraging implicit knowledge gathering, or implicit learning.

Sure You Know the Answer, But Ask Somebody Else Anyway!

The art of listening is one of the most valuable skills for a leader. Whether you're a team leader, technical lead, or simply more experienced than some of your colleagues, you'll gain a great deal by doing an appropriate proportion of listening relative to the amount of talking that you do. Remember, we're born with two ears but only one mouth; that sounds a good proportion for listening versus talking!

I've previously written about listening in the context of being a better leader/colleague, but there's more to the art of listening. If an issue or a challenge arises for your team, consider asking your team to propose a solution, even if you're confident you personally know how best to respond to the issue or challenge. You will benefit from making the team take responsibility, and it reduces their dependence on you - you don't want to be the cause of your team having a bus factor of 1!

Members of the team have probably faced a majority of the issues long before you joined. Remember, you are trying to help the team learn to work without your help; you're not trying to make your team dependant upon you. Sometimes, this means you have to let them make a decision that goes against your best judgement. Teams need to learn by their mistakes; and, in my experience, often times their idea works out, which means you can learn something too - and that's got to be a good thing for everybody.

"The Delegator" - Positive or Negative Epithet?

In a recent meeting, an action arose and I asked one of my team (PJ) to catch it and complete it. He (tongue in cheek) commented to all those at the meeting that I was "the best delegator" he'd ever worked with. His humorous implication was that I don't do any work, I just get other people to do it for me. I've known PJ for years and worked on many successful projects with him, so I was happy to be the butt of his joke. However, I see delegation is a positive thing, so it set me thinking about how different people understand the verb "delegate".

The dictionary says it means "to give a particular job, duty, right, etc. to someone else so that they do it for you". The fact that one is giving one's work to somebody else to do doesn't sound altogether positive, but if we accept that a team can do more work than one individual, and if we accept that a team needs a leader to coordinate and dispatch work around the team, then the team leader isn't delegating his/her own work, they are simply spreading the team's work around the members of the team.

However, in my mind, delegation is a tool to help the team learn and grow. And that means that I choose to delegate some of the management work to members of the team also. By doing so, I can coach them to learn new skills; and I inevitably learn new things as we go along too.

Not everyone wants to be a manager, but everybody needs to understand the objectives and challenges of management. Armed with knowledge of management, one can work in harmony with one's leaders and management. Moreover, it is often the case that the perception of the team leader's role is not a match for the actuality. For me, team leadership is about a) achieving more than I can manage on my own, b challenging myself and my team to do new things, c) helping my team members to become the best they can become, d) learning from others, e) enjoying the benefits of being part of a successful team.

So, "The Delegator", is it a positive or a negative epithet? In my mind it is a distinctively positive name. It means I'm helping my team to learn and grow, and I'm helping them with their career and their ability to enjoy their working days (and at the same time they are helping me to do the same).

You Can't Fire Everyone

Some years ago I was taught a memorable and valuable lesson by my erstwhile programme manager (we'll call him BJ). I was brought into the project to provide knowledge of i) business intelligence, and ii) software documentation appropriate for the regulated pharmaceutical industry. After a while on the project, BJ asked me to act as BI Delivery Lead. He promised me the ability to recruit a team but initially supplied me with two existing staff members.

After a week I went back to BJ and said he'd have to provide me with two different staff members because the first two a) knew nothing about BI, and b) were at each other's throats all day long. BJ told me that nobody else was available; I'd have to make it work. Then he put his hand on my shoulder and told me he'd especially chosen me to act as BI Delivery Lead because he knew I had good people skills. Flattery is a good management technique! But more importantly, BJ was teaching me an important team leadership lesson: developing people is just as important as developing software.

It's a lesson I'll never forget and, as I worked with my two staff members over the following months and we all achieved increasing degrees of success, I discovered that developing people can be at least as satisfying as developing software.

I was reminded of this specific lesson when I read Roy Osherove's You Can't Fire Everyone post on his 5Whys blog in December. Roy's blog is a treasure trove for those who want to become a better team leader. Roy typifies the process of team development as following three phases: the chaos phase, the learning phase, and the self-leading phase. Roy describes how to recognise which phase you're currently in, and how to progress and develop your team. Recommended reading.

The Bus Factor

What is your project's "Bus Factor"? If you don't know, or you don't know what the Bus Factor is, you'd better read this article! If you do know your Bus Factor and it's too low, read this article for some advice on how to increase it.

Wikipedia describes Bus Factor thus:

In software development, a software project's bus factor is an irreverent measurement of concentration of information in a single person, or very few people. The bus factor is the total number of key developers who would need to be incapacitated, (as by getting hit by a bus) to send the project into such disarray that it would not be able to proceed.

"Getting hit by a bus" could take many different forms. This could be a person taking a new job, having a baby, changing their lifestyle or life status, or literally getting hit by a bus: the effect would be the same.

It's name is irreverent, but it focuses our attention on a very serious point. I've worked on many projects where it would have taken just one specific person in the team to have met an accident for the project to have stopped or slowly died due to the huge loss of knowledge.

What is the Bus Factor of your team? What is the smallest group of people in your team whose loss would bring your project to its knees? Look around your team and ask yourself what would happen if each of them didn't come in to work tomorrow. If you find somebody whose disappearance would have a critical effect on your project then you've got a Bus Factor of 1, and you're at risk of big trouble.

The simplest means of improving (increasing) your Bus factor is to encourage sharing and collaboration amongst your team members. Share technical knowledge, and share knowledge of the activities in the team.

• Get a good spread of expertise
• Do peer reviews of code
• Don't encourage ownership of code. Expertise is good; ownership is bad
• Don't allow a name to be placed at the top of each piece of code
• If you don't have a daily stand-up meeting, you should at least have a weekly team meeting where everybody shares critical information
• If possible, have a weekly 20 minute presentation by a member of the team on something interesting they did last week. Make sure it's a different person every week, and everybody gets a turn

The biggest challenge is to make everybody dispensable. That sounds challenging, but it doesn't mean that the company will actually dispense of people. The positive view is to say that team members can more easily be moved from one project to another. And that makes them more valuable because they can make a wider contribution to the company.

Are you dispensable?!

BetterManagement Moves to the SAS Knowledge Exchange

I noticed that the oft valuable contributions at BetterManagement have moved to the SAS Knowledge Exchange web site. This was announced in a recent post from BetterManagement.

BetterManagement.com was formed in 2000 by ABC Technologies Inc.The aim was to launch an online service that provided a soft-sell style of message to potential customers. SAS acquired ABC in 2002, and hence BetterManagement too. The BM web site hosts an excellent collection of articles and on-demand webinars on a wide variety of topics, all of which gently lead the reader to consider the role of SAS software in the subject area. It will continue to be available until July 2011.

SAS tell me that content is being shifted to the SAS web site. To date, not much has been shifted. Searching the BM web site for "bicc" produces four hits, yet the SAS KE site produces none. Not a scientific test, but indicative nonetheless I think.

The four hits on the BM web site include an excellent business intelligence competency centre (BICC) audio & slides presentation by SAS's Stefanie Gerlach and Dagmar Bräutigam that I've watched previously. However, upon doing research for this article I was unable to get the presentation to roll. I hope this isn't a sign on an earlier than planned end for BM! On the plus-side, "Beyond Spreadsheets: Risks and Productivity in the Real World (video interview)" worked fine for me.

The Greatness Guide

I'm currently re-reading the humbly titled "The Greatness Guide: Powerful Secrets for Getting to World Class" by Robin Sharma. It's a nice easy read at Christmas time because each chapter is only a couple of pages long, so I can pick it up and put it down in between peeling the sprouts and fixing the Christmas tree lights (again).

It's an easy read, but that doesn't mean it's light on content. Sharma manages to offer 101 focused nuggets of advice for one's approach to life (professional and personal). Whilst the book can be summarised as yet another publication encouraging positive mental attitude and a can-do approach, Sharma's real-life illustrations manage to lift the book above several others that I've begun reading (but not finished).

Who Makes the Decisions to Cut Corners?...

We produce SAS code to solve business problems, right? Those business problems might be a simple question about recent sales figures (resolved by a quick ad-hoc report), or they might be allied to the ability to predict manufacturing failures so proactive action can be taken to avoid the failures. Either way, there's a business benefit which has a value attached, and usually there's a timeliness associated with it too.

For any significant piece of work, you will have some kind of plan as to how you will deliver the work; and that plan will include some element of each of the following standard steps (plus effort estimates for each):

• Requirements capture
• Design
• Build
• Test
• Deploy

Sometimes (often?!) the time and cost constraints come into conflict with the total effort indicated by the plan. In other words, the project manager says "you'll have to deliver sooner than the plan indicates, we don't have enough time/money (delete as appropriate) to do all of that". How do you resolve this apparent conflict?

What's It All About?

Since starting this blog at the end of July, I've received many kind wishes expressing appreciation for the information that the blog provides. However, I've also had a small number who have (politely) enquired whether the eclectic mix of topics is appropriate.They ask whether the SAS-related posts sit comfortably alongside the "other stuff".

This blog is headed "SAS and software development best practice". With the possible exception of our coverage of the Clipper Round the World Race, all of this blog's posts are written in the belief that they offer constructive advice or information for SAS developers. But what is a SAS developer?

Listen: Be a Better Manager/Colleague

We all need a wide range of skills to be successful in the working environment (and outside of it too). Being great with SAS syntax should not be considered the sole measure of success at work. Good developers need to be skilled in (or have an appreciation of) design & architecture, testing, project management and (most importantly) communication. In this post we discuss a key communication skill that is so often lacking in our colleagues and managers: listening.

Whether we're a manager with staff who want to feel they're listened-to, or we're a developer with customers who want to feel they're listened-to, it's easy to think we're good at listening but how can we be sure. Here are a few tips for checking to see if you're a good listener:

1) Be Questioning. Do you ask as many questions as you are asked? When we're in a social setting and are asked "Hi, how are you" our natural response is to say "Fine thanks you, and how are you?". In the business setting you can do the same thing, e.g. "What's our top priority project?", "It's currently WonderWeb, do you see any other similarly high priorities?". A key tip here is to not interrupt while your question is being answered!

2) Be Seen To Act. Do you confirm that you'll act upon what you've been told? If you are questioning then you'll be given feedback; do you assure your listener that you'll act on what you've been told? "That's a great new feature suggestion, Jim. I'll put that into our backlog with a priority of 2. Okay?"

3) Focus. Does your listener feel that they are the most important person in the world to you at the time of your conversation? Maintaining eye contact (not looking over their shoulder) will assure them that you're focused on them.

4) Empathy. Do you put yourself into the shoes of the other person? Try opening yourself to the talker to the point where you can actually feel what they are feeling. Become, in small part, the person you are listening to. Standing in another's shoes and seeing the world through their eyes allows you to listen empathetically. Practice will give you the ability to see a situation simultaneously from multiple points of view.

5) Be Tough. Do you encourage tough questions, or do you try to avoid them being raised? If they're important they'll bubble to the top eventually anyway, so you might as well encourage people to raise their tough questions sooner rather than later. It gives you more time to resolve them.

You can practice your listening skills on a day-to-day basis. I've seen success with the adoption of Rosa Say's Daily 5 Minutes (D5M) working pattern. It's aimed at managers but is equally effective when used amongst peers. In a nutshell, Rosa suggests giving 5 minutes of no-agenda time to at least one member of staff or colleague per day. You can keep a simple log and rotate around the team day-by-day. It's 5 minutes for you to listen to whatever the talker wants to say. As with many successful techniques, it's simple and doesn't sound like it would be of any benefit, but I assure you it can work. Read Rosa's text and give it a try!

Rosa says in a recent blog post:

Managers who are humble are the ones other people will work hard for. A humble manager listens really well. She asks the people reporting to her what they think, and why, and what they would do about things.

You don't need to have all the answers; your job is to find them. And people who can't learn to be humble have a hard time learning where to look for those answers. Sometimes things are right there in front of them, and they don't even see.

Humble managers see with their ears, not with their eyes.

It's almost poetic!