How do you convince decision makers in your enterprise to give a machine learning (ML) project the green light? You might be super excited about machine learning – as many of us are – and might think that this stuff should basically sell itself! The value proposition can seem totally […]
Getting the green light for a machine learning project was published on SAS Users.
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:
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!
Follow me on Twitter: @aratcliffeuk
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?
Follow me on Twitter: @aratcliffeuk
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.
Follow me on Twitter: @aratcliffeuk
See an audiovisual recording on my SAS Global Forum 2013 paper Visual Techniques for Problem Solving and Debugging
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 relati…
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’…
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 regul…
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 descr…