Communication - how much is too much

In one of the companies I worked for, we had a ritual where every person sent monthly status reports to all his or her stakeholders. In that status report, an employee would write about his wins and accomplishments of that month, the challenges he was facing and plans for the following month.

The ritual had its merits. This was every employees’ chance to showcase his accomplishments for the month and to let the stakeholders know if he or she needed any help. It helped keeping status of the work that he or she was doing and above all serveed as a record of accomplishments that could be used during the year-end performance appraisals.

Having said that, this ritual was not without its flaws. As the saying goes - “the devil is in the details”. In the overenthusiasm of bragging about their accomplishments, people started writing long verbose status reports. Each status report started having at least one full page of accomplishment “stories” and then at the end just a few sentences of challenges and future plans. And as expected, people would spend 2 to 3 hours every month in writing, re-writing and polishing these reports.

Since the ritual was to send the status reports to all stakeholders, each individual contributor in the company would receive at least 20 such reports from various stakeholders. As a manager, I used to receive at least 30 of them! Very soon, I realized that it took a huge amount of time to go through all these reports and then to comprehend actual accomplishments from these long verbose reports was even more daunting.  

I had an alternative and often better (more relevant and up-to-date) route to get updated on current status and that was through my staff meetings. So I started skipping the long accomplishment part of these status reports and instead would go straight to the “challenges and future plans” part. This was to understand if that person needed any intervention from my side and then I would archive the status report in a folder.

One day while reflecting on how I use these status reports, I had a doubt if my stakeholders were reading the status reports I was sending them. Instead of just asking around, I decided to play a small trick. In the next status report I had to send, I copied the accomplishments from the previous month and sent it out! I had the current one ready so that in case someone pointed out the error, I would just say it was an inadvertent mistake and promptly would send out the current one.

My fear came true when not a single person came back to me asking why I sent old accomplishments! To convince myself it was not a one-off oversight, I repeated this experiment three times during that year, with same results.

Bottomline, each employee of the company was spending 2 to 3 hours every month on an activity that was getting wasted because no one was reading those reports. In a 100,000 people company that’s a wastage of 300,000 hours of productivity!!

I had three key takeaways from this small experiment:

1)      While lack of communication is harmful, over-communication can lead to wasted effort and we need to understand what is the right “dose” of communication.

2)      Communication is a two way process. If the receiver is not “receiving” the information, no amount of polishing of the content will help the sender.

3)      We should challenge our assumptions – in this case, the focus was on creating the report and it was assumed everyone was reading them. There are times when we need to critically look at our rituals and prune the unproductive ones. 

Addressing Responsiveness

Few years back I was asked to lead an effort to accelerate the “responsiveness” of our organization. Our organization developed, maintained and implemented software solutions. In a bid to become more efficient and effective at the same time, our General Manager had initiated few projects and increasing “responsiveness” was one of them. The definition and measurement around that were left loose and we were told to figure things out and implement.

To understand the work that had already been done in the industry, I along with my team started researching on the internet. What we found was responsiveness as a measurement was used mainly by call centres and customer support organizations. We could not find anyone in software development industry measuring responsiveness. So we started asking ourselves some questions and answering them as well:

What makes us more responsive?

-          If we can become faster in developing software and implementing them.

How can we do that?

-          If we can produce and implement software faster i.e. if we can increase the productivity of our people

How do we measure that?

-          If we can come out with a process to measure the size of our deliverables and then divide that by number of employee-hours spent to do that, we would have a measurement in place

We thought we had almost nailed the definition, so we started working the details. And that’s where we found ourselves lost. We had so many activities that could not be sized correctly. For example how would one differentiate between two enhancement requests, one of which required 15 hours of analysis and 20 minutes of code fixing and one which did not need much analysis but would require 10 hours of coding and testing. There could be so many permutations and combinations of these things.

The day of our first review with our General Manager was approaching. We thought we would put down what we had agreed so far and what we still needed to work on. What we heard from him was a bit of a surprise - he said “you guys are working on a wrong definition, increasing productivity will make us more affordable but not necessarily more responsive. Go and talk to the customers before you guys get into any more theoretical discussions.”

So we were back to the whiteboard. We went and talked to several customers and their feedback was “you guys take too much time to deliver”. We were confused. On one hand the customers were telling us that we take too much time to deliver and on the other hand our GM was saying it was not productivity increase that would give us the solution. How could that be?

Incidentally, around the same time I had some construction work going in at my home. The contractor was taking way too much time to complete the job. It’s not that his people were incompetent- they did good work when they turned up but there were days when no work would happen because no one turned up for work! As it turned out, the contractor was working on five different projects and he would juggle his people between these projects. One day, I was discussing my ordeal with my colleagues and one of them said “Well, that’s how these contractors are, they are not very responsible” Suddenly that gave me the idea, are we doing the same to our customers? Can we organize our workflow better to become faster?

When we started analysing our workflow we found several interesting things.

-          There were times when a solution was ready but was not getting implemented because some review was pending

-          At times, we were delivering similar solutions to different customers but we did not have a standardized workflow - hence each iteration was taking almost the same amount of time

-          The total elapsed time could be reduced by automating some of the standard procedures

-          There were places where we could deliver part of the solution quickly and work on the not-so-important parts later

So, we had our definition and measurement of the problem. It was not productivity gain but it was reducing the total elapsed time that we took to deliver the solution. We could reduce significant amount of elapsed time by optimizing the time when we were not working on the problem vs. taking less time when we were working on the problem.

It’s true that in the process we gained significant productivity, but we could have never solved the problem if we looked at productivity gain alone.

My learning from this journey was two-fold.

Firstly, it is very important to define the problem correctly before you start running to find a solution. Einstein once said “If I had 20 days to solve a problem, I would spend 19 days to define it”.

Secondly, it is important to look at things from the customer’s point of view. Our entire paradigm started shifting when we started talking to customers. What is even more enriching than listening to the customer is to be in the customers’ shoes. It’s only because I was frustrated with my contractor that I started seeing the problem differently and was able to drive the resolution to the problem.