Does your project management tool tell you how much effort your team is expending on your critical project? A simple calculation showed me that I was managing a house of cards that could come tumbling down unless I took action immediately.
We had implemented a new system to track our hours. Everyone entered the hours they worked and the projects they worked on each week. This data was to be rolled up and used to better manage our staff resources.
We had been entering data for weeks, but even as the Director of Software Development, I had yet to be able to see any information come back from all the effort. My requests to see the data on my departments was met with the response that it was not all working yet. So, we continued to stoically enter data, week after week.
It was at our weekly staff meeting that all this changed. The directors met with the general manager to discuss organizational issues in this meeting. Today, the COO from the corporate HQ was also attending the meeting. This was not too unusual, she dropped in periodically (see a related story in Being Slightly Out Of Control Can Be A Good Thing).
The GM pulled up a document he had carried in and started to read off work hour statistics about each of the director’s organizations. As he read off the average hours worked, each director looked a bit disconcerted. No one had had an opportunity to look at the numbers or even ensure they were correct. This was all new to everyone.
When he got to me, it was a real big shock. The GM reported that my roughly 100 software engineers worked an average of 38 hours per week! Strangely, he didn’t seem really unhappy when he told me this. I didn’t have much I could say except it didn’t sound right and I’d like to see the raw numbers. He told me everyone would be getting their data, soon.
The COO however, had an idea she wanted everyone to consider. The idea was simple. The data showed we had a very straight forward solution to our staffing shortage. We would just give everyone more work to do! Clearly, based upon the data, we had a lot of hidden capacity we were not exploiting. She left us with the notion that we were expected to immediately show more capacity to do work and to immediately take on more of the work available to us.
I got out of that staff meeting and “landed” on the project manager for the new hours tracking system. I wanted my data and I wanted it now. I told her that in the future I wanted to see my data before anyone on the senior staff did. She was not too upset – more apologetic. She admitted she had just received multiple phone calls from the various directors saying roughly the same thing at various levels of volume.
Unsurprisingly, the numbers the GM had reported were a bit off base. In fact, they were just plain wrong. Now, I had to use the data to find some constructive feedback to senior management. It would not be useful just to indicate the analysis was wrong. I had to take charge of my own data and show that it was useful to improve how I managed my workforce.
My organization averaged a 42 hour week. Still a bit less than I would have expected, but certainly not the ludicrous notion of 38 hours. I only had two part time staffers and everyone else worked at least a 40 hour week. I know, I was there. I came to find out that many people didn’t track their work closely and so just entered 40 hours each week regardless of the fact they worked more hours. I now had a better value for my average but this number alone didn’t give me any real useful insight into my organization.
I computed the standard deviation for hours worked (yes, hours worked is probably not normally distributed but it still generated some numbers that helped me think about my teams). The standard deviation turned out to be about ten hours. (See how your project management tool average can be powerful for more on good uses of simple statistics.)
I took a look at who on my team was working around 52 hour weeks. It turned out to be just about all my managers and most of my engineers who were considered the experts — the people everyone turned to for technical guidance. That made sense. It also gave me a confidence that my data might indeed be showing me real insight into my organization. I was concerned that the data captured might be essentially random noise and bare no relationship to what was really going on.
I then looked at the individuals who were working about 62 hour weeks. Again, primarily managers and experts. This time however they were predominately my elite folks. These were the people who were at the center of every major project and were the ones fixing the hardest problems. If we needed something very important done these were generally the folks who got the call.
At 72 hours, I could see some of these same folks, but individuals who worked 72 hours varied greatly by week. So I now had a notion, in broad groups, on the hours my staff was working. It lined up well with what I had observed with my staff and gave me an objective measurement of the effort they were expending. It also became clear the flaw behind the notion of just giving the staff more work to do.
All those engineers averaging 42 hours weeks relied upon the leadership and expertise of the managers and experts. Giving everyone more work would require more time from these managers and experts to support everyone. These managers and experts were already working 52 to 62 hour weeks.
I remember managing an effort in the Air Force where we had too few domain experts from the Air Force working with a large contractor force. Everyone was frustrated as the contractors couldn’t get the information they needed to do their jobs and the domain experts couldn’t provide enough support to anyone before they were pulled away to help someone else. Also, the domain experts — even as dedicated Airmen — still wanted to periodically get home to their families and to non-work activities to rest and recover.
I realized that my organization was built on a house of cards. If I were to lose a key manager or expert it would ripple down and impact many people. While I was aware of this in general, as any manager would be, it was made very clear by collecting and analyzing the hours people were working. I now had some reasonable data on which to base some concrete actions.
This is what I did based upon these insights:
1. Encouraged my key individuals to stay: I reviewed everyone’s salary. I discovered that some of my top experts were making less money than some new hires! The economy had been booming and was bidding up the salaries of new staff. For my key folks I was able to schedule a mid year salary increase and program in the maximum salary increase allowed by our corporate policy for their end of year salary review cycle. Yes, I had to make some cost trade-offs and fight some policy battles, but we recognized that staffing was a problem. That is what started this whole discussion on staff hours after all.
2. Grew more experts and managers-in-waiting: I had always focused on identifying and growing people who could step into management and leadership roles as needed. I had not spent as much time, I realized, on finding, nurturing, and growing technical experts. In either case, it was a straight forward matter of just knowing who they were, periodically seeking them out and encouraging them, and finding opportunities to put them into more leadership roles (management or technical). Backing this up with a salary increase, especially one that was mid year, helped to cement the notion that we really cared and appreciated their contributions.
I had managed teams for over 20 years before I was forced by circumstances into taking a good look, an objective look, at the hours my teams worked. It was one of those moments where I realized I had been flying blind all those years, thinking I was doing just fine with how I managed my staff. Now I’d found a simple and objective way of gaining real insight just by really understanding the hours my staff was working.