Be a great communicator

Effective communication is key to good leadership. As a leader you need to be constantly communicating with your team. You need to be providing them with direction, inspiration and insight. And you also need to be listening to them, clarifying your message, and addressing their concerns.

This is an important topic and it fills many books. I can't cover it all, but here are some guidelines for communication that I have adopted over the years:

• Be clear and consistent with your message 
• If you are trying to get your team to understand a new concept or to move in a new direction, it is very important that you make your point clearly. It is also extremely important to be consistent each time you give the message. Inconsistency can result in confusion. To do this well, you need to purposeful in your communication (your days of winging it may be numbered!). 
• Provide as much information as you can
• Over communication is better than under communication. Give as much context to the message as you can. The more people know, the better they understand what you are saying. I have found that explaining how I made a decision makes it much easier for people to accept the decision even if they disagree. 
• Repeat the message
• You will need to repeat your message for it to sink in. It may be unnatural for you to repeat yourself because you may feel like you are nagging or boring the team. But the fact is that you need to repeat your message until you see others talking about it; until the team has really internalized it.
• Tell the truth
• It is important for you to tell the truth when you communicate. I talked about this in a previous blog but because it is important I repeat it :-) . Don't make things up. Do your research. Know what you are talking about. 
• Know your audience
• Not all people will want or need the same level of detail in communication. If you provide too many technical details to a non technical crowd you may bore them. If you provide too few technical details to a technical crowd, they may think you don't understand the subject or that you don't understand them. In both cases, your message will likely be lost. 
• Make personal connections 
• It is very helpful in communicating to be able to make personal connections. In a presentation or a meeting, you want to be engaging the individuals. To help with that, you should make a point of getting to know the people on your team. And in emails, where appropriate, making a personal connection is always helpful.  If you want to highlight an accomplishment, it is best if you can be as detailed as possible, talking about specific people, teams, and actions. 
• Communicate often 
• You should be communicating with your team as often as you can. Much of it can be informal or one on one, but it is important to communicate with your whole team. This can be difficult if you have remote members of the team. You need to remember them. You need to make a real effort to communicate often to your entire team. A special note here regarding remote teams: it is important to know about and respect their time zone and their culture. Include the remote teams but do it reasonably. (My coworkers and bosses in Silicon Valley loved to call me after 7pm EST and on stat holidays such as Canada Day)
• Listen
• Communication is a two way street. You need to listen to what people tell you and use that information. If your actions show that you have listened, they are more likely to continue to listen to you. As well, if you are going to make an impact on an organization, you need to understand the organization and that is much easier if you listen to what the members tell you.  It takes time but it is worth it. At one job, I was consistently the voice of development for the executives. When I would get asked how I knew what the developer's thought, my answer was always the same ... I asked them and they told me. 

Although these guidelines can be helpful, if you don't use them correctly, you could end up in some trouble. To help with that, remember to avoid the following pitfalls:

• Empty communication
• You should never communicate with a team if you have nothing to say or if what you are saying has no real meaning. You have probably been in a meeting where you rolled your eyes, looked at your watch, or played games on your smartphone. Don't be the person who called that meeting! You have probably also read that congratulatory email that was so generic that it was meaningless. Don`t be the person that sends that email. Make sure you have something to communicate. 
• Interrupting your team
• Unless you absolutely need to communicate something right away, make sure that you are not interrupting your team. This is a bad habit that I have. I will often ask just because I would like an answer and not because I really need an answer right away. Development is a concentration intense activity and interrupting a developer and getting them to context switch costs time.  To avoid interrupting, I now usually swing by their desk or text them and ask them to drop by when they have a break. 
• Talking too much
• You can actually talk too much or too long. When you do that you waste people's time. I have worked for someone who loved to talk and could talk for hours. Although much of the information was useful, it could have been said in half the time. Don't take any more time than you need. Be respectful of their time. 
• Taking too long to respond
• There will be times when you get asked a question and you just can't answer right away, so you let the people know you will get back to them. Make sure you do. I have seen so many people say they will and then they either don't response or respond so long after the question was asked that it might as well have been left unanswered. People don`t forget it when you do this. The next time they have questions or concerns, they may just decide not to bother bringing them to you. This pitfall was the primary reason that one of my colleagues lost the faith of his team and eventually was moved to the side. He was genuine in his wanting to understand the issues but never did a thing with the information he was given. 
• Keeping secrets unnecessarily
• It is necessary some time to keep things confidential. But too often, information that is not confidential is kept secret. The thinking is that not everyone needs to know everything. That is true, but people like to know what is going on and giving them information is almost always beneficial. I have seen too many times when rumours started just because of a lack of information. And as we know, rumours can be very disruptive. 
• Surprising your team 
• This is one area where I tend to get a lot of disagreement when I make this suggestion. My view is that you should not completely surprise your team (unless you are throwing them a party!). If there is big news (good or bad) or a change you are trying to make, I recommend bringing in a few key people and talking to them about it in advance of the wider announcement. Then when you roll it out to a larger group, although some will be surprised, not everyone will, and having people other than you who understand the change will help. This approach takes more time and planning but if there are any concerns, it will come up in these early discussion and you can adjust so that your message becomes clearer and more impactful. 

There are many ways of communicating and many facets to communication. Solid presentations skills are essential. One of the best resources for this is Power Presentations. Jerry Wiessman's book, Presenting to Win, is pretty helpful but if you have the opportunity, I would highly recommend taking his course. Jerry is very knowledgeable and the course provided me, my peers, and my team members with effective and immediate tools for improving our presentations.

Email can be a very effective way to communicate, but use it wisely. It should not be a substitute for face to face communication. In my next role, I am going to insist that email is something that is only read two to three times a day and is for sharing information that needs to be written down but not actioned immediately. Instead of email, I encourage you to to walk over to see them, pick up the phone, or open a chat window and have the discussion that way instead (but try not to interrupt them when they are concentrating). Reading email should not take up most of your day. If it does, there is something wrong. Trust me. I have been there.

I have a similar concern regarding meetings. They are a great way to communicate but they need to have a purpose and they need to have minutes that document the outcome. If it was not worth writing down, then it was not worth having the meeting (the exception to this is one on one meetings with your team members where minutes are not necessary). I have lived the scenario where I had 40 hours of meetings most weeks. It resulted in me not paying attention in the meetings, not having time to listen to my employees, not having the time to get my messaging clear, and generally resorting to after hours email for most of my regular communication. The meetings started a cascade of bad communication habits that were extremely hard to break. I will never get myself into that position again. If you are there, find a way to get out. You probably don't need to be in as many meetings as you are scheduled to be in (ask to read the minutes!).

Communication is very important and must be done wisely. I have been reading a lot lately about agile and lean methodologies. Among other things, these methodologies promote keeping things simple, focusing on adding value, eliminating waste, and empowering the team. A lot of the guidelines I have provided are aligned with these principles. Don't waste your team's time with communication - make sure it is adding value and giving them the information they need to make their own decisions. Keep the communication simple but make it effective.

Reverse Leaders - from HBR

I wanted to share this article on Reverse Leaders from an HBR blog. It was not a term I had heard before. Reverse Leaders are those true leaders in the ranks of the company. You should be seeking them out, supporting them and engaging. Check it out.

Find the Reverse Leaders in Your Midst

Be Trustworthy

You must be trustworthy to be a leader. When things are going really well, it is pretty easy to get people to follow, but when things get tough (and they inevitably do), they will only follow you if they really trust you.  Trust is something that is easy to earn but unfortunately even easier to lose. And regaining trust is pretty difficult (you don’t get to act like a teenager and sob and beg to be trusted and promise you will never ever ever ever break their trust again).

In order to be trusted, you must

·         Be Credible

·         Be Fair

·         Be Open

·         Mean what you say; say what you mean

Be Credible:  As a leader in software, you must be able to speak intelligently about the product you are working on, ask insightful questions about it, and make good decisions regarding it.  You do not need to be smarter than everyone, but you must know enough that the people following you believe you are a capable contributor; that you are adding value.  If you rely on your team for every decision, they begin to see you just as a gate keeper, paper pusher or meeting attender, and they no longer really trust you (or perhaps they never did).  You don’t need to be the expert in every subject but you do need to know enough to be conversant – read all of the design documents, play with the product, do research into competitors, look at the code – stretch yourself, embrace learning. It will pay off.

Be Fair:   The Merriam Webster definition of fair is “marked by impartiality and honesty; free from self-interest, prejudice, or favoritism”.  As a leader you must treat people fairly. That is not to say that you must treat people equally; but you should be prepared and able to defend any inequalities. There will be times when you give someone a promotion, or a special project or a bonus; and you should be able to explain to others why this one person was singled out.  When you treat people fairly, you are respected; when you treat people unfairly, the team will notice and will lose faith in you.

Be Open:  It is important to be open with your team. Telling the truth is very powerful. So explain how decisions are made; tell them when you disagree with a corporate decision but explain why you must follow nonetheless; tell them when you made a bad decision and why the current one is the right one; tell them when you don’t understand something, or let them know that a change may be coming before it impacts them. People generally dislike surprises, change, and edicts from on high. The more information they have the better; keep them in the loop.  Do not mistake being open and telling the truth for telling your team everything; there will be plenty of times where you do need to keep information confidential. But whenever you can, do communicate and be open with your team. They will appreciate it.

Mean what you say; say what you mean.  Expanding upon this could take an entire blog post, so I will only touch on the highlights regarding trust. Leaders need to:

• Keep commitments. If you set up a meeting, go to the meeting on time. If you say you will write an email, write it. If you say you will get back to someone to help with a problem, get back to them. Better to under commit than under deliver. If you meet your commitments, your team will learn they can rely on you. 
• Make people accountable.  Just as you must keep your commitments, you should hold your team accountable for their commitments.  If you ask for something to be done, you must make sure that your team did it. And if they did not, you need to address the issue. The team will know that when you ask for something, you really mean it. 
• Only ask for what you need:  If you ask for things and they are never used, people will begin to doubt you. So, make sure you only ask for that which you need, otherwise you will be viewed as someone who wastes others' time. 

I can't emphasize enough how important it is to keep your commitments. If you keep yours, your team is more likely to keep theirs.  You can't fake it. The only way to act "holier than thou" is actually to be "holier than thou". In this area, you really need to lead by example.

Being trustworthy is key to being a great leader. When your team trusts you, you will be able to lead them to complete seemingly impossible tasks. Do your best to earn and keep their trust. 

Vision and Strategy

Creating a believable vision and strategy can be a Herculean task especially if you have not done it before.  It is an area where I personally have struggled a lot. For a long time I thought it was the sole purview of the CEO and the executive team.  Certainly for the corporate vision and strategy that is almost always true. But software engineering teams need to have a strategy too. It can often be implied, especially on a small team, but having it explicitly stated is beneficial. 

The strategy and the vision, or lack thereof, can have a huge impact on the team so it is important to get it right. It defines the approach to getting the work done; it provides the daily context for the team; and helps set the culture.  There are many ways to go wrong.  Here are a few ways that I have experienced first-hand:

• Going without – this can result in an ineffective team
• Ridiculous – you can lose the team this way
• Incomplete – you can do the wrong thing
• Inconsistent with the rest of the company – this creates conflict 
• Incomprehensible – you thrash

Hopefully by seeing some bad examples, you can avoid the same pitfalls, and set a good strategy and vision.  Because if you do it right, you can get everyone on the team motivated and going the same direction and that is a beautiful thing.

Going without

Early in my career, I thought it was all about detailed planning. Given a comprehensive plan the team would simply do what needed to get done. But that was far from the truth. On a fixed price program where we got paid on milestone deliveries, I was unable to motivate my team to complete the work. The problem was that the system that had been specified and approved as part of the contract signing process was not technically sound (i.e. it would not work). But we were contractually required to deliver what had been specified. After floundering for a while, I got some good advice; tell the team the truth. I told them my long term vision was to develop a workable system but we were going to have to do it in a roundabout way. The first step was to do the design for the system that was not going to work, to confront the clients at the design stage, prove that a subset of the requirements were incorrect, show an alternate approach, rework the contract, and then get ourselves back on the right track. There was no project plan that could communicate that. But with this knowledge the team was able to get the necessary payment milestones done without having to spend too much time on work they knew was going to be thrown out. And once that was out of the way, they started to focus on the doing the work the right way.  By setting a believable vision and approach for the engineering team, I was able to get them on track, and focus on getting the program corrected. It was simple and effective.

The ridiculous

I once had a VP of Engineering, who had come to the company from a completely different line of work and from a marketing background.  We were a systems shop where the real value was in the software we developed. We had 3 products we were barely supporting and were being asked to do a forth with no staffing increases.  The new VP spent a few weeks assessing the situation and told me that even though everyone was working hard, we needed to stop doing so much and focus on one area only to be successful. His solution was to “focus on software”. Say what? This did not provide any focus and worse than that indicated clearly that he had no understanding of what the team did.  Several people left after that announcement, me included. 

The incomplete

On another team, our VP of Engineering gave the edict that our focus was on quality first.  It made sense; since our focus in the past couple of years had been features, features, features… getting them to market as soon as humanly possible. Unfortunately, quality had suffered as a result. But his strategy for improving quality was not complete. The stated (and measured) strategy was to fix bugs quickly. Clearly fixing bugs was an important part of the problem but that was primarily a tactical effort.  There was also a need to fix our requirements definition, to attack the technical deficit we had accumulated, to rework several major subsystems, to make the system more serviceable for the support team and to improve our system testing.  We needed to build quality into the product and not simply try to fix it after it went out the door. But given what was measured (and the punishments that went along with failure to comply) the team focused on bug fixing only, and the rest of the quality initiatives suffered. The results, as far as I was concerned, were predictable and not good.  The escape rate for bugs did not change and so much effort was spent on fixing fielded bugs that feature development suffered. Eventually, after his departure, the focus was reset and the strategy for attaining better quality was expanded. 

The inconsistent

At a company with 3 development sites, the unwritten but commonly stated vision of my site’s engineering group was

• Performance is a key factor in the product’s success.
• Everyone should strive for technical excellence.

The team I worked with rallied around it and worked hard to deliver excellent code and a product that’s performance was second to none.  We argued to find get the best technical solution to a problem and we hired only the best engineers. It was great, or at least it seemed great for a short while. The problem was that the vision was not shared between all the engineering teams yet we all worked together on the same product. The other teams were focused on quick feature addition to address short term customer needs. The result was that each site was very loyal to their own team but did not like or trust the teams in the other site (my site was considered a bunch of elitists and the other sites were considered to be thoughtless hacks) and the product suffered. Without alignment, it just did not work. 

The incomprehensible

At one company we had a strategy and vision that was loved by analysts, marketing, and the execs.  We were showing market leadership by creating a new market and had a staged approach for achieving the vision. It seemed perfect.  But to the product team the vision and strategy were incomprehensible. The current product suite had only a tenuous relationship to the new market. The strategy was staged but the steps were amazingly large and literally required technological miracles for them to be completed in the required time frames (whether the strategy authors knew it or not).  So both engineering and product management struggled. Some progress was made but essentially the product road-map stayed in chaos for a couple of years. As the realization sunk in that we had not made any product or sales progress that would help forge this new market, we retrenched.  Several executives left the company and the vision and strategy were reset. 

The ideal

I don’t have a prescription for getting to the right strategy and vision for your team. But here are some rules that I follow:

1.  It needs to be the truth.
2.  It needs to be attainable but should stretch people.
3.  It needs be understandable.
4.  It needs to be consistent with the corporate vision and strategy, and with the approach of other teams. 
5.  If possible, it should inspire people.

On one team that was just starting out, we used the following template:

Vision: We are developing a world class [specific solution] for [our customers] which will provide [this specific value] at this [performance level]. 

Strategy:

Create a base product that we can put into beta test within a year of starting that

a.       Provides at least [this specific level of value from the vision]

b.      Supports this [minimum performance characteristic]

c.       Fits seamlessly within the customers operational framework

d.      Clearly shows the value to the customer

Ensure that the initial product works for the customers by

e.      Addressing all major issues noted in the beta program before the initial release

f.        Release product updates on a monthly basis that

                                                               i.      Fix customer-visible bugs

                                                             ii.      Improve the serviceability of the solution

                                                            iii.     Improve the value of the solution. The target goal for the value after 12 months of real world experience is [this amount].

Follow up with a product within the next year that

g.       Improves the performance [to this level]

h.      Works on the same equipment as the initial release with an easy upgrade path

i.        Gives the development team visibility into how to continuously improve the product

The team was motivated by this strategy and vision. They used it to make good product decisions; as it helped clarify what was important and what was nice to have. It did not replace having detailed requirements but provided context for the requirements. It worked. The initial product and dot releases exceeded management’s expectations.

  

If you were starting with a clean slate, you could just say “Do the right thing”. That might work but it would take a pretty rare (or extremely small) team to make that successful. If I could start with a clean slate and was developing a consumer software product, I might have the following vision for my engineering team.

1. Keep it simple (eliminate any unnecessary complexity in our systems and our product)
2. Add value (make sure whatever you are doing is adding value to the organization,  to the product, or to the customer) 
3.  Be collaborative (the team is more important than the individual)
4. Innovate (we win by changing the game).

Of course, we would need a strategy to support this, but you can imagine having

1. Architecture/design/code reviews that ensure we are looking at the simplest solution.
2. Regular meetings with customers to ensure that we are truly adding value.
3. Days set aside with no agenda, just an opportunity to let be people innovate.

So give it some thought. Set a vision for your team. Make sure you believe what you say and that you can defend it. And whatever you do, don’t repeat the silly mistakes that my managers or I made.