Stop Being Nice

I suppose it is not the right time of year to telling people this, but stop being nice. Niceness is not correlated to success. All of us know someone who is really nice, but being nice is not the same as being effective or being a good leader/manager. It may be hard to make the adjustment, but it is necessary (I know because as young woman I worked hard at being very nice). You can be genuine, you can care about people, and you can do great things all without being nice. Now, that doesn't mean being rude or offensive, but it does mean standing your ground and saying what you think. And that may just mean that sometimes people won't like you. Its time to get over needing to be liked by everyone. Check out the following:

From HBR Blog "The Morning Advantage" Dec 3, 2012 by Sarah Green

"Being liked is overrated," writes Jessica Valenti in The Nation. She's primarily writing about women — for whom likability is negatively correlated with success — but her advice is useful for the yes-men out there, too. Valenti, the founder of the blog Feministing, admits to wasting hours online responding to every commenter, giving equal time and attention to both the thoughtful people and the snarkiest trolls. "It pains me to think of what I could have achieved if I had that time back."

When we adjust our behavior to be more likable — withholding our most deeply held opinions so as not to offend, agonizing over every bit of negative feedback, eventually "tempering our thoughts" as well as our words — we stunt our selves, our careers, our impact in the world. "The truth is that we don’t need everyone to like us," she writes, "We need a few people to love us."

I'll give Valenti the last word: "Yes, the more successful you are — or the stronger, the more opinionated — the less you will be generally liked. All of a sudden people will think you’re too 'braggy,' too loud, too something. But the trade off is undoubtedly worth it. Power and authenticity are worth it." It's a piece worth "liking."

Time for reflection

Usually at this time of year, I am working on a speech for the company holiday party. My goal is always to give a meaningful and entertaining message. So I begin to reflect on the past year - all the things we accomplished, the occasional disappointment, the new people we added to the team, the people who left. The speech gets done but more importantly, I am compelled to review the year, put it in perspective, and consider what my team and I should be doing differently in the future.

At my current company, our development process includes a biweekly retrospective, where we review the engineering processes and procedures and make changes as needed. There are places to look at the company's progress from a financial standpoint on a regular basis. But there is no place in the business where we look at how we are doing as leaders. I am going to make a change so that on a quarterly basis we do take time out to do a level set to "measure and learn" so that it becomes part of the overall company process. The details are not yet figured out but it will be something simple. More importantly, I believe it will be something that is effective as we are working hard to establish a culture that accepts change and thrives on continuous learning and improvement. 

I encourage all of you to do some reflection at this time of year (and on a more regular basis).  If you need some help on what kinds of things to do, here is a year-end checklist from Inc. to give you some ideas. 

Be Prepared

As a leader you need to think ahead, work out contingency plans, see when a course correction is needed, and generally always be prepared for what is to come. At work, this comes naturally to me.

Home is a bit different. The recent devastation of Hurricane Sandy coupled with my daughter doing a talk for her English class on the Zombie Apocalypse made me think about my personal emergency preparedness. Was I ready? The answer was a resounding no. Today, I made it a priority. It was not that hard. Within a few hours I had a decent kit ready and enough food and water for my family for 72 hours. The food has been labelled so that I can either eat it or donate it to the food bank in advance of it expiring.  And I have a really cool urban multitool. I should have done this years ago. But now I am ready.

If you do not have an emergency kit, don't delay any longer. Information is available to help you get started at http://www.getprepared.gc.ca/index-eng.aspx.

Be ready when the Zombies attack!

The importance of networking

In this day and age of social media, it is pretty easy to have a large network of contacts. Without trying I have 287 LinkedIn connections and 117 Facebook friends. But I recommend having real connections with real people. It is easy to do that with the people who surround you at work, but having more widespread connections is really what you should strive for as that is a lot more valuable. Why? Well, you never know when you will want to hire someone, change jobs, need some advice, and without a wide and very real network it will be difficult for you. How do I know? As with most of my lessons, I learned it the hard way.

In my previous company, in the last 5 years, I made no real effort to get out and actively network with people in the technology community. I had many excuses which included:
-"I don't need to network, I have great people right here at work if I need anything"
-"I want to give the opportunities that I see to some of the younger people here; they should do the networking"
-"I am too tired to go to a breakfast meeting and then work my regular long hours"
-"LinkedIn is a great way to network"

As you can see the excuses were weak. Truth be told, I just didn't feel like doing it. I got lazy. And that was fine until I decided to change my career and partner in a startup. I wish now, that I had spent more time keeping up my connections instead of cocooning for the past five years. Because I did that then, now in my new company hiring was harder, getting advice on lawyers and accountants to use in the area was harder,  getting first hand experience in what we should do in our startup was harder.   My LinkedIn connections were pretty useless as I mostly had connected with people who I knew at work or people who did not live in my local community and so could not help with the problem at hand (side note: LinkedIn turned out to be a valuable tool for recruiting but not until I built a good local network and paid them for additional services).

I am not the only one in this position. In the last short while, as I build my local network, I have met many people who did not nurture their personal local network and now are having to start over. For some who find themselves without jobs, the struggle to build a real network is immediate and when you are under pressure it can be a daunting chore.

The good news, however, is that with just a bit of work, it is straightforward to fix. You need to get out there, reach out to people you once new, get introductions, go out to coffee, go out for lunch, join the local community groups, join local interest groups, talk to people you don't know but would like to know, join a breakfast group, watch the twitter feeds from local organizations to learn about events, etc. I found it quite tiring at first - too many new people, too many new things .... but the real problem was me. As usual, I was trying to accomplish something immediately with my contacts. That will never work. Just put yourself out there, but don't force it - make contacts naturally, and see what comes of it. The goal is to build a network of local contacts that you might someday use or that you might someday help. It is a two way street. Since this "epiphany" my network building has been a lot more interesting and fun. And I consider it a valuable use of my time and part of my work, not just a side activity.

From my new network I have gotten some great advice; I have been put in touch with some talented people that I might some day hire;  I have learned about interesting tools that I now use on a daily basis; and I have a newfound respect for what is going on in technology in my community. A lot of upside for a small amount of consistent effort.

If you don't have a local network, start building one before you really need it. If you have one, good for you, but don't forget to keep it going. Social media is interesting and provides a lot of unique opportunities. But good old fashioned face to face networking is irreplaceable.

What women know about leadership that men don't

I read and enjoyed this article from the HBR.

http://blogs.hbr.org/schwartz/2012/10/what-women-know-that-men-dont.html

Trust

A while back, Eric asked what I thought the role of trust is in a dynamic organization. And can trust scale?

I believe that trust is an important part of an organization culture. With real trust:

• employees have great job satisfaction
• they can focus on doing their job well, confident that others are doing theirs well
• they can ask questions and make suggestions to help the product or the business, without being considered overly critical (i.e. they are free to speak their mind without recrimination)
• they can innovate and pursue freely in their area of responsibility

• organizations are streamlined
• there is very little overhead needed for management at any level
• no need for policing functions (as HR can sometimes grow to become in an organization)

I have worked in organizations where there has been real trust:

1. As a student, I worked for a Telecom company who was rolling in money. Our management was young, enthusiastic, and had the ability to decide what our team would do without any interference from upper management. The team was smart, the work was interesting and we made great progress. We were confident and no one questioned what we were doing. It was invigorating. But then the company's resources began to dry up and as cuts began, trust began to erode.  Although our work may have furthered the company's goals, the path to success was not clear and there was another group attacking the same problem in a different way. Instead of cooperating together, we were essentially competing, using  at least twice the necessary resources to achieve the results. Throughout the company there were many projects that were duplications, dead ends, or seemingly unrelated to the goals of the company. Groups were cut, budgets slashed, command and control replaced trust. The company did survive but it was a completely different type of company after that.  
2. Early in my career, I worked for a consulting company which gave me well defined constraints: the scope of work, the delivery schedule, and the resources. Once I was given a project, they fully trusted me and my team with completing the work, as long as we reported good progress each month. However, it was pretty easy to trust everyone, since there was so little room for any variation or any innovation. 
3. I also worked for company that had been stripped to the bare bones with cutbacks and all we had left were the people who wanted to make the company a success, a leader who we believed in, and a plan that we thought would work. We had no choice but to trust each other to do their part of the plan as we were under resourced in all areas. Everyone was motivated and criticism was all taken as constructive. After we turned around the company, trust continued for a short while, but then we started to grow quite rapidly, we hired more haphazardly, we brought in executives who were micro managers and the trust that we had evaporated. Trust had not been a core value of the company but more of a side effect of the position we had found ourselves in.

Although I have seen organizations with real trust, I have not seen it scale for any length of time. For trust to scale I believe that

• everyone needs to have clear direction and needs to be working toward the goals of the company
• it should not be as restrictive as my consulting company example, but it should not be a "free for all" like my Telecom company example
• trust must be a core value of the culture
• and you must work to ensure it stays that way; even though there may be trust at some point, if it is not key to the company culture, it can erode as in my comeback story
•  you must have a great hiring process
• you need to make sure that you hire talented people that fit in and share your values

Leaders are readers

Good leaders are always learning. They are avid readers. 

Needs some ideas on what to read?

Here are some ideas from HBR Blogger, John Coleman, on what leaders should read. 

I checked out the the curriculum and reading list from David Gergen's leadership course and thought it looked excellent. (Side note: I am a big David Gergen fan. I can even tolerate CNN political coverage if David Gergen is there, as I find him to be thoughtful, sensible, and balanced)

But reading does not need to be just about leadership. Below is a consensus cloud visualization of several top 100 books lists on the interweb (put together by David McCandless of Information is Beautiful - for the full data set check here). 

I have often thought of picking a top 100 book list and reading it as a New Year's Resolution. I probably will never do that but reviewing these book lists has inspired me to read To Kill a Mockingbird (hard to believe I have not read that) and True North: Discover your Authentic Leadership. 

Don't ask if you are not ready for the answer

When I was a young teenager, I remember asking my Dad to make a decision for me although the decision really could have been all mine. He chose an answer that I detested and I proceeded to throw a fit. When he saw my reaction he told me "Never ask a question if you are not prepared for the answer". I have long forgotten the question I asked but I have always remembered his great advice.

If you are a leader or manager this is very important. If you are not prepared to accept the answer to a question you have asked your team, then you should never have asked. Asking and then dismissing can be quite demoralizing.

Recently, my daughter was asked by the leader of her division if she would like the opportunity to take on a new expanded role in the company. He asked her to do some research and paint a picture of what the role and responsibilities would be. Two levels of management above her had left in the course of the previous 9 months, and she had taken on many of their responsibilities but there were more to take on. Her interim performance reviews had been stellar. She took him at his word, went and defined the role, picked a title and found out what the competition paid for a comparable job. She reviewed her findings with me and it all seemed very reasonable. Since she was new to the position, she was going to ask for a a lower than average salary until she could prove that she could handle all aspects of the job. The promotion would result in a $15k increase in salary (yet still $15k below the average salary for the work).

As requested, she sent her findings to the division head in advance of their scheduled meeting. He called her after seeing what she sent, said he was shocked, and there was no way she could possibly expect that she could get that big a raise. He said she should just be grateful for the opportunity he had given her. The meeting did happen but he pretty much said the same thing to her in person as he had said on the phone. Eventually, she got a token raise along with no title change yet he was more than willing to give her all the responsibilities of the job she had defined.  She was also told if she increased profits she could possibly get a raise (but profit sharing bonuses were not available to someone at her level). My daughter told me "well, it was better than a kick in the pants".

Why then had she been asked to "paint a picture"? The only reason that I can come up with is that the division head needed a job description and this was a way to get it. The net result is that although the opportunity is good, it has clearly taught her that he doesn't care and cannot be fully trusted; and she is now somewhat demotivated although still putting in a good effort. My take on what we learned about her division head and her company is pretty colourful in tone and not appropriate for this blog (I have also recommended a resume update). Clearly he never should have asked the question, because he was not prepared for the answer. The result was that a young enthusiastic employee feels under appreciated and overworked. She lost something in the experience; her division head lost something in the experience; and the business lost as well. All because of a question that never should have been asked.

Decision Making

Found this short blog post from Seth Godin on decision and thought it had some very good points. Check it out.

http://sethgodin.typepad.com/seths_blog/2012/10/waiting-for-all-the-facts.html

The Importance of Team

The team is everything. This is not news. In order to get things done, you need to have a solid team. In order to do great things, you need to have an outstanding team. Most people know this. Most people fully agree with this ... why then do we have so many problems with our teams?

The number one problem I have seen is that people become willing to compromise and take any interchangeable carbon unit just to fill the job. Perhaps they are tired of interviewing (it can be a very tedious process). Perhaps they just figure they will never find the right person so the kinda ok person is fine. But most of the time, no-one is better than the wrong person. It may be hard to see, but there is a real drain on the team to bring a new person up to speed, and to get them going, particularly if they are not a good fit for the team.  The effort of covering the empty spot is often quite a bit less than dealing with a bad fit.

The second problem that I see is that insecurity will stop people from hiring outstanding candidates. I learned a long time ago that you want to surround yourself with individuals who are smarter than you are. It can be intimidating at first, but the results are fantastic. I have seen hiring managers who say they only want A players but in fact they are hiring B+ players so that they maintain the status of the smartest in the room. The difference may appear subtle but the results are not. Development teams should be built of incredibly smart people. 

The third problem is that when hiring managers make a mistake and somehow the wrong person gets on board. Very few are then willing to deal with it in a timely fashion. It is hard to let someone go.  But keeping a bad fit on your team is almost always damaging to the team, the product, and to you (because people either see you as unable to act [i.e. make a f**king decision] or worse, unable to see the issue).

I sympathize with the first problem.  I am struggling with this right now. I am building out an R&D team in a startup. The opportunity for people joining is fantastic, in my humble opinion, because of the responsibility and the potential financial upside. But getting the candidate stream flowing, and finding people with the breadth of skills I would like to have with the right personality fit for the team continues to be an arduous task. 

I keep reminding myself that my patience will pay off. I remind myself that if I do hire the wrong person, I may be stuck with the third problem above - having to remove them from the team. But I am also rethinking the criteria for hiring. I am willing to give up on skills that I would like to have if I can get someone who is smart, adaptable, with the right attitude, solid experience, and who has a personality fit with the rest of the team. Skills can be learned, but you cannot change personalities and you most certainly cannot "teach smart". 

Remember the importance of team. The best way to be successful is to surround yourself with great individuals who mesh together to form a stellar team. 

Are you sure you're not a bad boss (from HBR)

This article lists what makes a bad boss in terms of what they did not do. It is pretty consistent with my views.

http://blogs.hbr.org/cs/2012/08/are_you_sure_youre_not_a_bad_b.html

Make a F**king Decision

You have probably been in a situation where you just wish someone would make a decision so everyone can move forward. It is frustrating. The lack of decision can stop a lot of work, and waste a lot of time.

If you are a leader, you need to be able to make decisions. And you need to make them promptly. The real issue for you may be that there doesn't seem to be enough information to make the right decision. That is often the case; but taking time to get a lot more information can result in delays which may be just as detrimental as the wrong decision.

Early in my career, I used to hem and haw before making a decision. Nine times out of ten, the decision I would have made was the same as the one that I eventually made (but much later). I had to learn to trust my instincts, rely on the advice of others, and take a leap. I also had to learn that when the wrong decision was made, I had to admit I was wrong, suck it up, and reset the course. That may seem hard, but it actually works well. People will appreciate this way of working and will appreciate having you as their leader.

I recently met up with an ex-colleague who said he had not fully understood how great it was to have decisions made until he worked for another manager (after I left) and prompt decisions became rare. In my group, decisions were made quickly and things got done. My colleague hadn't really noticed that anything special was happening - it seemed like the natural way to work. However, when he changed groups, he really noticed the difference. When decisions didn't get made, developers made their own micro-decisions and the group did not all work toward the same goal; the results were terrible - virtually no forward progress was made in months.  I know the managers in this group and they are all good, smart people. What they are not, however, is bold. I have seen them get trapped in "analysis paralysis" more than once. Being decisive takes courage and is hard to do. But it is essential, if you want to be a great leader.

Some good advice I got once from my husband (a colleague at the time) was "Lead, follow, or get out of the way". He had been in the Navy for a while and this was one of many useful lessons he took away (as a side note, he is also an excellent bed maker and can iron like a pro!).  I always remember this. This is a mantra worth repeating and teaching others.

So go out there and make decisions. Lead. Be bold. And occasionally, if you are wrong, admit it, change course, and move on.

P.S. My post title was inspired by Adam Mansbach's book "Go the F**k to Sleep". Check out Samuel Jackson reading this book on YouTube if you are not familiar with the book. It is pretty funny.

Taking Risks

Some people naturally love risk. I have skied, I ride a Harley, I have backpacked through parts of South East Asia but I am not a natural risk taker. Truth be told, I liked to ski on green and blue runs, I bike with full gear all the time, rarely in the city, and never in bad weather or in the dark. And when I went to Asia, I didn't have reservations but I did have detailed plans and always kept to the safe parts of the countries, never traveled alone, and had several guide books with me. I am rarely seen as a risk taker or a thrill seeker in life.

The same was true at work for me. I was naturally inclined to follow the well known paths. But I got good advice early in my career that made me view risk differently at work, and made me more willing to take bigger risks. My greatest successes came when I followed these two simple rules:

1. I was told to trust my own judgement and make things happen. If I saw a new or better way to do things, I should go for it. Leaders lead they don't follow. Sadly, my early tendency was just to complain about what was happening even when I could see a better way. It was much more satisfying and effective to take the risk to lead and fix the problems.
2. More importantly, I was advised that "if your stomach doesn't hurt a little, you probably aren't taking enough risk". A mentor of mine, Randal Leavitt, shared that with me in my late twenties after I told him that I was feeling very queasy on my current project because there were so many unknowns. He pointed out that that was good; with risk will come rewards. He did add that if I felt like vomiting, that was probably too much risk :-). I took his advice and my project was very successful. I still use "the stomach test" to this day as it has never let me down.

If you want to be a leader then you need to take calculated risks. You do not need to take crazy risks but you are not a leader if you just do standard repeatable mundane tasks. Challenge yourself and challenge your teams. Make a difference.

Less confident people are more successful

I liked this article in the HBR.  I am one of those people who consistently questions themselves. Despite being a consistent high achiever, I used to really lack self confidence. But over the years, I learned to trust my judgement and my abilities, and gain a reasonable amount of confidence. But I still avoid "winging it" and like to be prepared, I am still self-critical, and I believe that I rarely seem either arrogant or deluded. Looks like my lack of confidence, which troubled me for some time, was really a helpful trait.

10 ways to motivate your team

Leaders are typically good at motivating people. It is not always an easy task but here is my top 10 list on how to do it:

1. Give people a challenge

Talented technical people want to be able to solve problems. There is a real sense of accomplishment in finishing something that is hard. If the work itself is not really challenging at the time, find a meaningful way to add some difficulty to it. For example, a sustaining team can be challenged by been given the opportunity to rework some of the poorly written code instead of just fixing a series of one-off bugs in the code.

2. Give people a good understanding of what they are doing

Try to set as much context as you can for your team. Give them the big picture of the product.  The more they understand the "what" of the work, the better they can figure out the "how". I was recently reminded that it is good to know the "why" as well, to give people a real sense of the business and its value to customers.

I think it is also helpful to say what you are NOT doing. Its rarely stated but can really go a long way  in keeping the focus. It is a good tool to stop requirement creep.

3. Have clear goals and expectations

Make sure that your team has clear goals. These should be regularly reviewed and updated, if needed. And don't confuse tasks with goals. Yes, people need to know the daily work they need to accomplish but they also do much better when they have the higher level expectations and goals. I found that providing quarterly goals and reviewing/adjusting these worked really well (and I was not a big fan of this approach before I tried it out).  The advantage is that you get into a rhythm and the team members remember to keep the high level goals in mind.  It also allows you to overlay career goals/personal goals onto the product goals. Because there is more to work than just the task at hand.

4. Give people responsibility and authority

Let the team have responsibility and authority for the work. Trust them. You should be there to guide them but not to micromanage them.  When people get to have control of what they are doing they are much more motivated.

5. Give people the recognition they deserve

It is important to give people recognition for a job well done. You should not take the team for granted. When someone does something worthy of note, you should point it out, and congratulate them.

6. Care about your team

It is well known that if people feel that they are getting attention, their performance is higher ( the Hawthorne effect).  I used to show I cared by feeding my team home made cookies. But as groups get big, the amount of baking can be overwhelming :-) A better way is to get to know the people through conversation. You should be spending quite a bit of time with the team during work hours and talking to them (not idle conversation but real discussions about what they are doing). Side note: Yes, there will be some people who you don't necessarily care for that much.  Learn to fake it!

7. Eliminate the bullsh&%

To keep your team focused you need to keep the irritants away from them. Doing this won't motivate your team but not doing this will definitely hurt the motivation. Lots of valuable time will be spent complaining instead of working.

8. Make money a non-issue

Pay your people well and take the issue of money off the table. You won't see developers work harder because they make more. But you will see them work less if they feel like they are not paid enough. They view the lower pay as not being valued.

As for special bonus programs, I have never seen these programs really work. In fact the $50 spot bonuses at one company were probably just as effective as the $2k bonuses because what really was working was the recognition.

9. Set an example

If you want your team to be motivated, you need to be motivated yourself. The team will see if you don't care about what you are doing. It is hard to be "on" all the time and so you don't need to be but if you don't believe in what you are doing, you need to change something. Either find a way to get engaged or leave. Because if you are not motivated, your team will not be either.

10. Engage a few people to help motivate others

You don't need to motivate the entire team by yourself. Sometimes it is easier to motivate a few key players and get them to influence and motivate the people in their sphere of influence. Another trick is to get the typical naysayers on board. You don't use them to motivate people, you just get them to stop demotivating people, which they easily and often do by saving negative things or pointing out problems (and then you should really ask yourself if it is worth continuing to have them on your team).
----

Hopefully these tips will help you to motivate your teams.

I have not had any formal Organizational Behaviour training but I did get MBA training vicariously through my husband (he got the real deal). He mentioned Frederick Herzberg to me some time ago. If you are interested in his thoughts on motivation and leadership, check this out:
http://www.businessballs.com/herzberg.htm

Dan Pink also has some interesting ideas on motivation in his book Drive. Check out this video. Even if you don't agree on the content the presentation is very entertaining and well worth the 10 minutes. http://www.youtube.com/watch?v=u6XAPnuFjJc

Is your organization stuck?

I read Seth Godin's blog regularly. It doesn't always resonate with me, but I really enjoyed his post called Understanding Stuck. Partly because every time we fly my husband comments sarcastically about how lucky it was that they explained how seat belts work. But mostly because I have worked in organization that got stuck.

Many of us in the organization tried to make changes to get us unstuck, but typically we were told "No, you can't change that. This is how we do it here.", when we tried to fix a broken process or tool.  The ironic part for me was that I had established a number of these processes. Now, years later I was being stopped from making necessary changes. There seemed to be some mysticism about how we worked; as though the processes had been handed to us, fully developed, from on high. It was frustrating. We did get things changed but it took an extraordinary effort. We definitely could have used a clean slate. I wonder if we would have had the courage to take that step?

If your organization is stuck, I would give the clean slate prescription a try.

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.

So you want to be a leader?

If you take a leadership course, read a book on leadership, or scour the web for resources, you will see that there is no set formula for being a great leader.  However, there are common traits and qualities of leaders that are mentioned time and time again.  You can even find the A to Z of leadership qualities on the internet which includes Xenophilous as a trait (ya, had to look that one up and I am not sure I agree … but it was entertaining)! 

 

The best leaders I know have the following qualities:

1.       They have the ability to create a believable vision and strategy.
2.       They are trustworthy.
3.       They are great communicators.
4.       They are persuasive and can motivate those around them.
5.       They are willing to take risks.
6.       They can make decisions.

In the next set of posts, I will go into detail on each of these, giving examples of the great things that can happen if you make proper use of this quality and the ugly side of things if you don’t.

The good news is that you can learn these skills. Some will come more naturally than others. For example if you are very charismatic, motivating people will be easy for you. But even if you are not, there are ways that you can be persuasive and get your team excited about what they are doing. If you are shy then being a great presenter takes some practice, but listening is just as important as talking when it comes to being a great communicator (this is not obvious to everyone, sadly) and often shy people have more practice at listening.

Now, you may not agree that these six qualities are the most important. There certainly are others that I considered for my list. But these are the ones that I value in people who lead me or who are part of my team in a leadership role. In a past company, I had a CEO and an architect with these qualities and they were two of the best leaders that I have seen in my career.  At first blush, you might not have thought that these two people shared the same qualities. One was a very outgoing person who seemed to relish attention, the other quiet and reserved who was happiest coding away by himself in his office. But in many ways they were quite similar.

The CEO could set a clear vision, communicate it, and get people motivated. There was a time at the company (during the dot bomb years) that we had a 5-1 reverse split, our stock was down to about the $1 level from a high of over $180, we could no longer spend money like a bunch of cocaine addicts and had  to lay off more than half of our staff. Despite all of that, he came up with a vision for a company, a strategy for turning it around, and then was able to get key members of the staff to be believers.  It was a big a risk. There was equally as likely a chance that we would fade and wither away as that we would succeed. The CEO loved risk if it came with a big reward (me ….not so much … taking risks was always something I needed to work at).  But it was not a foolhardy risk as he had a talented staff that he got to rally around his vision.  He made sure that we were really believers by using a technique that we eventually called his “are you in or are you out?” speech.  After a strategy discussion or presentation he would ask whether or not we were completely committed to the strategy; by asking if we were “in or out” and saying that if we were “out” we really should leave. He would judge our commitment by our reaction (the occasional person did leave but most stayed). Once, after a particularly hard day where I had agreed to take on more responsibility and had laid off more staff, he asked the question at a late night planning meeting.  I was a bit angry when I answered “how much more do I need to be “in” to prove it to you”.  That to him was a good sign regarding my commitment. During the 3-4 year period that it took us to pull through, he was forced to make many a hard decision and he did.  In the end, under his leadership we saved the company, became profitable, and made a name for ourselves in our new market.  In retrospect, given the facts of the situation, it is hard to believe that I made the decision to stay with the company. But it was my trust in the CEO, his clear vision for the company, his ability to make me understand it so I could guide my team effectively,  and his ability to keep me and my peers motivated through those tough times, that made it one of the greatest successes in my career.

The leadership skills of the architect were similar but looked very different to most people. He was very skilled in the software business with a wide range of experience. His technical papers and technical presentations were superb. They lacked the showiness and humour of the marketing presentations but were incredibly comprehensive, well laid out, and easy to understand.  He had a gift for making the difficult topics accessible to the entire engineering team and for providing a clear approach to solving technical problems.  He was always interested in feedback on his work; in fact, he was very uncomfortable when he did not get some kind of meaningful critique or thoughtful question about it. It was not that he lacked self-confidence but it was that he wanted people engaged and he wanted the communication to be a dialogue; his papers were not to be taken as an edict.  He was not only a technical guru; he understood the importance of balancing engineering requirements with business needs. He could make tough decisions when they needed to be made. He used to come to me as his manager and tell me “time to shoot the engineers and ship” (I still make use of that phrase). He knew when people were really tinkering and it was going to do us no real good to keep coding.  He would recommend short cuts when they were needed and would also stand up to disagree vehemently when he felt the wrong technical or business decision was being made.  Despite personally being a very risk-averse person, he was willing and able to take calculated risks at work.  This was something that he learned to do as it did not come to him naturally. The engineers and management trusted him, valued his communication skills as well as his problem solving skills and knew that he could make seemingly impossible things happen on an engineering team.  Despite being very different from the CEO, he too, was a great leader. *

With some practice, you can improve your leadership skills. Think about the six qualities. Have you met leaders in the software industry that had these qualities? Can you emulate their approach? Which of these qualities do you need to work on the most? Start there. You can start taking more risks. Or you can start practicing your two-way communication skills. 

There is one other quality that leaders have that I did not put my list, simply because I think that it is something that applies to everyone in the software industry. You should always be learning. If you want to broaden your skills in leadership and management, an easy way to start is by following Harvard Business Review on twitter or subscribing to their daily blog notices in email. They have excellent free resources on their site.  I spend a few minutes each day on their site and sometimes hours if the information is particularly interesting. If you have other resources like this that you read daily, please share them with me. 

*I would not normally name anyone that I describe here but I would like to acknowledge the excellent work of the architect described in this post: Tom Kelly. I had the pleasure of working with Tom for over 14 years at 2 companies.  He was a real treasure. Tom passed away last June and is sadly missed and fondly remembered each and every day.