Trust but Verify: How Much is Too Much Autonomy?

Problem

"Our new feature development team was completely invested in meeting a critical deliverable that the sales team had been counting on to make their quarterly quotas. The development manager had been managing the progress of the 5 month development and two weeks prior to the scheduled Beta release I was informed that we are going to miss the commitment... by a lot (up to 8 weeks). That sinking feeling hit the pit of my stomach..."

Actions taken

First off, I was not pleased with the tracking of progress and why was it so late that I was hearing that we were in trouble? After all, the process we had put in place had the developers in charge of making the estimates and commitments. I understood having a slip in one feature, but this appeared to be almost across the board. I asked the manager of the strategic development team if my instructions of "not making any changes to the developer's estimates" had been followed. This was important because I wanted the developers to feel ownership of the commitment.

"My experience was that commitments and deadlines that managers made typically were not met."

I was assured by Tom, the manager of the group, that my instructions were followed. So, the next course of action was for me to meet with the development team. It was a tough accountability meeting with the developers, where I stated my disappointment with the team because these dates were their commitments and I expect the team to be in "do whatever it takes mode" to meet them. The room was silent and I left.

Later, one of the engineers timidly came to my office and said "Dave, I understand your frustration, but you said something about these dates being 'ours'?... they weren't. Tom had taken all our commitments and systematically reduced them by 30%." Crap! I thanked him for his candor and I promised to take this under advisement.

My next call was to Tom to ask him to come to my office. When I confronted him, he admitted to changing the estimates because he felt the team had been padding them. I was furious. I now had a manager that had lied to me as recently as that morning about how the process had been followed. I excused him after telling him that I was making a change and would inform him by the end of the day.

I considered firing him, and certainly I was well within my rights to do so. I also considered demoting him back to an engineer. At this point, I conferred with my other managers to get their view/perspective on having Tom report to one of them as an engineer. Tom's expertise was also in an area that we were particularly thin in.

So, we decided to keep him, along with a warning regarding the integrity problem I had witnessed.

Lessons learned

"Trust but verify goes a long way here. Having process and controls are one thing, but without follow up, you just don't know..."

I still believe strongly in developers making the commitment to making a date/functionality. Every time there has been a problem with sizable schedule blowouts on my watch, there has always been an element of this at the core of the problem. This also seems to be a problem when you scale Scrum up to a large project where investors and executives need to see forecasts and plans before approving the budget for a new/large project with sizable risk. You're typically making commitments/estimates before the project is even staffed.

"Did I make the right decision to keep Tom vs. firing him? I think this was the right decision. Tom went on to deliver quite well with software he was an expert in. He paired up with another developer for about 3 years, before changing careers and companies to go into sales."

While making employee performance management a public thing is not only unethical, but illegal; it was very clear to see by members of the engineering organization that Tom's demotion was due to not following the instructions we had agreed to. It was a humbling experience for Tom and I think the engineers saw there was some compassion for not firing him.