Communication and recognition at work

I’ve seen this countless, countless times. A developer works on a production issue tirelessly for days. They troubleshoot, coordinate with several teams, get the fix ready, test the fix – then coordinate the move to production. Then, once in production, they follow-up with the original users – have them test, and do a final sign-off. What happens next? They send an e-mail like this:

image

What an unbelievable, and complete waste!

What’s wrong with this?
There are several things wrong with this, for example:

  1. For anyone not up to speed, it doesn’t explain the problem nor the fix, nor the timeline, nor the people involved. This is a waste of an e-mail, and an extra phone call for you because they are going to want more details.
  2. For those involved, it doesn’t show any appreciation for their efforts – and minimizes the effort it took to resolve. That will annoy them.
  3. For those end-users affected, it doesn’t explain the problem or solution – or give any confidence that the problem won’t be back. There is no useful information here.
  4. For you, this is unprofessional and not an appropriate way to communicate. It also wildly understates what it actually took to fix the problem – selling yourself short.

In short, this is a near-useless response which at-best: annoys people, at-worse: offends people. Worst of all, not only do you come across looking like you don’t take the outage seriously – you also misrepresent the effort it took to fix it. I would assume from the response above that it wasn’t a big deal, to you. That is going to annoy others that were involved, and especially the end-users – since it WAS a big deal for them.

So on every level, for every person involved – including yourself, this sort of response is just a wasted opportunity!

What should I do instead?
First, is your mindset. For end-users, this is a big deal. Treat it like a big deal. Treat the problem like a first-class citizen. Take it seriously. This means acknowledging the problem, working on it, and communicating effectively with regular updates. Most importantly, is summarizing things afterwards. Let’s create an example.

Fictional Scenario:
Let’s say that now that you’ve added 100 more users onto your website, now you are getting really slow performance. You work with the infrastructure team to look at perfmon on the server, and with the networking engineers to use Fiddler to see response times. Then you talk to DBA to talk about load on the server. In the end, you see that the app is using one, shared SqlConnection for everyone – so all database calls are being run serially. You change this to use the connection pool manager (by wrapping the code in a using {..} block) – and that resolves it.

*By the way, I’ve worked on a couple of issues in the past several weeks that had a similar technical details to the above, but this truly is not related to those in any way. This isn’t a dig at the project managers or developers. I’m just using this as a fictional example of communication!

If I’m the “owner” or manager of this problem, here is how I would typically communicate that. Here is me acknowledging the problem at 9:30am:

image

after working with infrastructure and DBA, I send an update at 11:30am:

image

after working through and testing the fix, I send another update at 1:30pm:

image

we deploy the code change, check with the users and the problem is fixed. What now – should I send this???

image

No, of course not! I would send this – and this can be a little longer, and more detailed – but it also include headings, it can’t be a “wall of text”!

image

Some things to note: look at the distribution on each e-mail, the subject line of each e-mail, and note that except for the summary – I tried to stick to 3 short paragraphs. The summary should be written at a “manager” level of detail. This then becomes something your manager or the business can forward to others. If you include code or go into the weeds, it won’t be useful to this audience.

Analysis:
Let’s take a minute and analyze this approach. Let’s start by looking at this from another perspective:

  • How would you feel if you were BusinessUser1? Probably validated, and that this person is on the problem! They are taking care of it, and they are competent! Right?
  • How would you feel if you were one of the support areas (infrastructure, network, dba)? Probably validated, and good that you were publicly acknowledged for working on the issue, and being useful.
  • How would you feel if you were this persons manager? Probably relieved that your subordinate has “got things covered”. This person is definitely not a squeaky wheel. I am fully confident that they are going to take care of business and only involve me if they need escalation of some sort. I’m also pleased that these e-mails have all the details I need, because if my mgr comes to me and wants an update, I can forward ANY one of these e-mails or just summarize them. My subordinate did all the hard work for me! How professional!

So, this is the same situation. The only thing that is different is how it was communicated. The business user is very happy with the outcome. The enterprise groups you worked with are happy, and happy to work with you in the future. Your boss is happy with you because you take care of business.

In additional to all of this though, if you have a good manager, you’ve now also set him up to get recognition from his boss, and his bosses boss. The summary e-mail is reasonable to forward to management. It goes into some technical depth, but it’s not over-the-top. Any IT executive should (hopefully) find an e-mail like that useful. So now, you not only fixed the problem – but you have helped make your department look good, and got your name (in a positive way) on your bosses-boss desk. This means you start to make a name for yourself too – that you “get $%^t done!”. Standing out as someone who appears competent to your management, is only a good thing – career-wise!

So – everybody wins, and there is no downside that I can see.

Bottom line:
So, what is my point here? To me, it’s a shame when someone does a bunch of work, and they stop right at the 99% mark – and don’t get recognition for what they did. You might think this is bragging or boasting, but it’s not. it’s primarily communicating in an effective and helpful way, and it’s fundamental to being seen as a very useful professional.

You are only as useful as how well you can communicate!

We’ve all worked with technical people that either didn’t communicate at all (like above), or they were so pompous that you couldn’t work with them. Instead, ideally, why not be effective AND communicate well with your peers and your customers?

One other HUGE benefit of this approach, is keeping track of a history of what happened. We’ve all had situations where “yeah, I remember we had a similar problem earlier in the year, but I can’t remember what the fix was”. Worse, as you dig through your own e-mail, you run across this piece-of-junk again:

image

Not only was that useless when I first sent it, but it’s infuriating to see now – because I need to know WHAT the solution was! So, you spend some time trying to piece together e-mails from 8 months ago to glean what the actual fix was. I wish Previous Robert would’ve written more detail!

Conversely, there is no better feeling than finding the “complete” summary like up above. It tells me:

  • When it happened
  • Who was affected
  • What was done to troubleshoot and who was involved
  • What the problem was
  • What the solution was
  • When the fix was released

ALL of this is useful when you are troubleshooting that future issue. So, I challenge you – the next time you have to own something, like an outage:

  • Take credit for what you do.
  • Communicate early-and-often to your users and manager.
  • Acknowledge the help you got from others.
  • Keep your manager in the loop – ESPECIALLY for things that might flare up. Never let your manager be surprised about anything!
  • After the event, take the time to succinctly summarize: what happened, the timeframe, who was involved, the problem, and the solution. Document it for Future-You who is going to be reading it in a year from now!

Again, this is truly to everyone’s benefit – there is no downside!

Posted in General, Organization will set you free, Professional Development, Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Archives
Categories

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 5 other followers

%d bloggers like this: