Effective Leadership Through Communication

Being a professional developer means that you are responsible for delivering software on time that works. It's a satisfying job - you solve the problem at hand and if you do it well, the feature works and is easy to maintain.

Being a development project lead means you are responsible for the entire project being completed on time. It can be a satisfying job, but often problems are vague and if you do your job well, it may not seem like you're doing much at all.

The switch between developer and project lead can be difficult. Leads often come from the ranks of the strongest developers, but the skill set required from a lead is very different from the set exercised on a regular basis for a developer, especially in the realm of communication.

Over the past 7 years I've come across quite a few communications techniques that I've found to be indispensable in fostering strong consultant/customer relationships. This list will not guarantee the success of any project alone, but it will allow you to identify problems quickly and avoid unhappy customers.

Determine Expectations

In addition to knowing the goals of the project and the expectations of your counterpart, it's important to get the full picture.

Everyone has a boss, and that boss wants to know what's going on with their projects. When I'm leading a project, one of the first things I try to learn about is who my counterpart reports to and what his/her expectations are in addition to the goals of the project. By getting the full picture, it's easier to understand what the concerns are and what to provide to the customer to help them feel comfortable.

Manage Expectations

Never leave a question or task unaccounted for. If the customer has concerns about something and you don't know the answer, that's fine. What's not OK though is having a vague plan to get an answer and they are left wondering what's next.

If something needs follow up, determine who's going to find the answer and when they are going to have it. It doesn't even have to be right away - everyone is busy and most things aren't high priority. Just determine a deadline that works for everyone and stick to it.

Over time, if you consistently meet these deadlines, you build trust with the customer as you gain a reputation for doing what you say. This trust is critical to a smooth project.

For your own sanity - establish the lines of communication for urgent issues. You can't always respond to emails immediately, and you shouldn't if you want to get anything done during the day. One approach is to let everyone you work with know that a phone call is the best way to get a hold of you immediately, otherwise it may take a while to reply to an email.

Keep Everyone Updated

As a developer, it's easy to get tunnel vision. The primary question I get as a developer is "Is your feature done?", and I do my best to make sure the answer is yes.

As a lead, you're the hub of information. Some people need to know about a current feature set, others about the next round of estimates, and another set about 3rd party licenses. You're often not responsible for these things getting done, but you are responsible for knowing the status of each of them so the customer knows.

Find out the most pertinent information and share it with everyone that needs it. This can be a summary email or a few minutes during a planning meeting devoted to updates. If there is some information that not everyone needs, scale back the communication.

Never Deliver Bad News Over Email

Email may be the worst way to deliver bad news. It lets the recipient stew in unpleasantness until the next meeting and more often than not, it allows them time to misinterpret the problem.

If I have bad news to deliver about a missed deadline or an unexpected roadblock, I will always call to let the customer know, or have a discussion in person. I get the bad news out of the way and focus on what to do to account for the change in plans.

Speak up & Say No

When working with a customer, it's not enough to say yes to every request. If the project fails, you'll able to say that you did what was asked of you, but that's a callous way of doing business and likely to lead to a short list of prospects for the next project.

Good customers are looking for partners in their projects - a group of people that are invested in the success of the project and determined to solve problems the right way. A good lead makes sure that if it looks like the project is going down the wrong path, they speak up right away and disagree, or say no and provide an alternative.

This technique can be the most difficult, but it becomes easier as trust grows. If you've proven to a customer that your invested in the success of their product and business, they will understand that disagreement doesn't come from a source of combativeness but concern.

Conclusion

Like I mentioned above, these techniques alone do not guarantee the success of the project. What these do lead to is a sense of trust and partnership, which lets you zero in on the really hard problems to solve with the entire team.

Again, this is just one perspective on communication when leading a project and I would love to hear more from anyone else out there with similar experiences. Find me on Twitter (@mjansen401) if you'd like to chat!

Mike Jansen, Software Craftsman

Mike Jansen has spent the past 7 years in pursuit of quality, maintainable code in the world of software development.