Blogging AYE 2007 Day 2, continued….

The session that I really wanted to talk about was “Communicate Effectively with Upper Management” because I thought it might be easier to communicate some of my learnings from this session. I also felt like this session applied to the masses at Intelliware.

This session was pretty high profile, three of the other conference organizers were in the working group (12 people). Esther Derby, Johanna Rothman and Gerald Weinberg were all part of the session which made it pretty special. I know some of the folks at Intelliware have recently had interactions with Esther. She’s great! In fact Deth has implemented some of what he learned from her at a conference earlier this year.

Even though this session refers to “Upper Management” it doesn’t just pertain to that group. It pertains to communicating with Teammates, Team Leads, Project Managers, and the Architecture Office.

The most important learning for me from this session was realizing that you need to understand what is important to the person you are communicating with. For example, does the person you are communicating with care about time, money, or resources? (to name a few) I think we have all been in the situation where there was some pain in a process or team we wanted to address. We talk about the pain, maybe complain about the pain. We never really address it properly.

Sound familiar? Here’s a hint, technical debt, the build is too slow, Subversion vs. CVS, or we don’t refactor enough. Too often these comments fall by the wayside. Project pressures push them aside, or the person who has “the power” doesn’t understand the cost of these items.

Next time you come across one of these items try this approach. Try presenting the information in one of the forms listed below.

  • If you do X, you will get Y
  • If you do nothing, it will cost you Z

and always follow up with….

  • Can we move ahead with X?

The ‘Y’ is the big sell point, this is the item that will really grab the attention of the person who is receiving the proposal.

The statements above are very simple but very effective. If you can describe the pain and solution in a way that the person you are telling can understand, it will empower them with the ability to make an informed decision.

If you can’t frame your concerns in the above structure, perhaps some more data is required. For example, on my current project we talk about and mention technical debt. We rarely make it a priority. Why is it not a priority? Well, I would throw out there that nobody really understands the cost of this debt. Recently a group of people decided to list some of the technical debt and measure the cost of bringing the debt along with us during development. This is brilliant!

It is brilliant because initially it would have been tough for the team to express why the technical debt should be addressed. Not only does providing some data make the facts clear and concrete, it also gives tangible information to the team lead or project manager to take forward as a concrete business case for making a change.

I hope this helps!

It's only fair to share...
Share on Facebook
Tweet about this on Twitter
Share on LinkedIn

Leave a Reply