Story telling is an important method of communication. I’ve been guilty of being too abstract in some of these blog posts. There are times when I’ve not used enough real-world examples, or told stories to help bring to life the recommendations. Use story telling to drive your message home.

Leaders are examples. You are being watched. Others will scrutinize your behavior and evaluate. Your team will infer all kinds of things about you from how you act. When you bring your bad day from home to work you create all sorts of confusion.

I believe in doing as you expect your team to do.  Model the work-life balance you want from your team to get the best results.

How does confidence factor into decisions making? Confidence in decision making is important, but probably not how you think.

I recently watched the movie Everest about a fateful expedition to the summit twenty years ago where eight people were killed. The movie has some seriously sad moments. The story highlights some leadership lessons that I couldn’t help recount as I thought about the story.

When you’re teaching, you’re leading. When you are in a position of having deep expertise, it puts you in a leadership position. We may be used to being the expert in a particular subject, yet we may not realize the leadership role which comes with teaching that subject to others.

Your technical leadership role includes building an organization. Apply some of the lessons from building software products to your role building organizations to get great outcomes and more satisfaction.

There is a romantic notion that we should be passionate about our work. I’m not convinced we should all aspire to passion in our work. As a technical leader, I don't think you must be passionate to be effective.

As a technical leader you are being pulled in more and more directions. You are forced every day to choose what to do in the few hours you are given. There appear to be no end to urgent demands on your time. It is tempting to think you can be efficient and do more than one thing at once. Do not.

One of the key aspects of being an effective technical leader is using your time wisely. As a leader, you begin to realize that time is the ultimate limited resource. Nobody has more than twenty-four hours in a day. No matter how big your responsibility, you only have twenty-four hours to spend on everything - work, home, family, self.

The middle of a long project can be difficult. It can feel like you are in the doldrums when you cannot see the light at the end of the tunnel. There are things you can do when you find yourself in the doldrums on a project or in your career. I have some tactics that will help you break free.

Technical leadership is required even in (especially in) situations where a team is self-organized. There are a number of "no managers" structures, I reflect on one known as "programmer anarchy", that are gaining traction these days. In a self-organized team that imposes its own regulation, I argue everyone must lead in some fashion.

Not everyone should work for themselves. The idealized state of working for yourself has hidden challenges that you don’t get prepared for by becoming great at your special talents. Learn what is involved in starting your own company before taking the leap and ensure you know what will be required of you. 

I’ve often wondered how accessible the Watson technology is for those of us in technology outside of IBM. Watson has APIs that are available and a cloud service to run all kinds of interesting applications. I had the pleasure of sitting with Anita Govindjee from the IBM Watson Healthcare group and she shared some thoughts with me.

As a leader from a technical background, I’m used to wanting to minimize risk. I am not comfortable giving an estimate without a lot of detailed requirements. Being a leader involves taking risks and being willing to work without all the information you might desire.

The common occurrence of big IT projects failing is not a new development. As technical leaders, we have to be mindful of the perceptions of our executive peers and work to manage projects to achieve the necessary outcome for the business.  I’ve been a part of my fair share of big IT projects that have failed. We must confront the cognative bias that drives us to be overly optimistic and allow projects to fail.

We all have to deal with e-mail as a core communication tool. Maybe you need help from someone. Maybe you need someone to know the information you are sharing. It is important that people want to read your e-mail. You can write more effective e-mails by following some simple steps and making a few changes before you hit send.

You are paid to deliver results. You are also pulled in lots of different directions and you will go home every day with some work not done. You need to make good choices about where you spend your time. Here are three tips to use your time and deliver maximum results.

I recently listened to an HBR podcast interview with George Mitchell, former senator and leader of the negotiated peace in Northern Ireland. Mitchell talks about the importance of patience and perseverance in the negotiations he conducted. It jumped out at me that you don’t hear a leader often reflect a behavior such as patience and perseverance. Leading organizational change requires both. 

I see technical leaders fall into a trap of not getting noticed for the good work they do. I see some people actively avoid trumpeting their contribution because they see it as self-aggrandizing. It is your job to add value, and also be sure people know about it. Keeping it to yourself doesn’t help your organization, nor does it help yourself. You need to deliver value and communicate it.