I once worked with a guy who told me that employees are like children, and you should only tell them things that will make them happy.
Let me tell you a story: An engineering team is preparing to release a new prototype for testing. It’s the prototype of a new product that’s supposed to start shipping in the fourth quarter of the year, so hitting every deadline is important. There are mechanical assemblies, electronics and software all coming together for this prototype and, as usual, there are hitches. Some of the mechanical parts need handwork (like drilling a missing hole), one of the printed circuit boards has been delayed, and the software can’t be fully tested until the rest of the system has come together. Hitting the prototype release deadline is going to be tight at best.
It’s a Friday, and the deadline is 10 days away (one week from Monday). In the daily stand-up meeting, the team’s manager says that the final parts are supposed to arrive in four days (Tuesday). He’s trying to get all the engineers to verbally commit to the Monday deadline of a running prototype delivered to testing in six days (including the weekend).
Everyone around the table agrees that hitting the deadline is possible, if everything goes right. But the engineers at the table are pretty sure that the probability of everything going right is small. So the manager isn’t getting the kind of “go team” response he’s hoping for, because he’s expecting engineers to completely ignore Finagle’s Law: Anything that can go wrong, will go wrong—and at the worst possible moment. Like just before a deadline.
There’s also the issue of the deadline itself. Missing it may or may not impact the final release of the product to manufacturing (there are lots more things that may not go right over the remaining months of development). While the fourth quarter of the year typically sees more units sold than any other quarter, the company wouldn’t be seriously affected if the product didn’t start shipping until the start of the first quarter. No one’s given the engineering team a plausible explanation for the current deadline. There may not be one.
So, the engineers aren’t quite as gung-ho as the manager might like. And they probably smile to themselves a little in response to his exhortations, or exchange a “yeah, sure” over coffee in the break room. But this is actually a very high-functioning team. All its members are committed to producing a great product as quickly as possible.
The problem with managing experienced engineers is that they have pretty well tuned bullshit detectors. No matter how much management might like to believe otherwise, you can’t push certain things past a certain point (nine women can’t have a baby in one month). Experienced engineers know you can berate a vendor into committing to a Tuesday delivery, but that might be Tuesday at 9 a.m. or Tuesday at 6 p.m., or even Wednesday at 7 a.m. Or next week, if you happen to be a small account and there are bigger customers for the vendor to please. And we know that product ship dates are frequently arbitrary (and perhaps even ill-considered). Sure, if you’ve pre-announced that a product will ship on a certain date (like “before Christmas”), you have a hard deadline. And missing it can sink a company (see: Osborne Computers). But that’s not always the case. As we used to say, “No one will remember if you ship on time, but they will never forget if you ship crap.” And in most cases, that’s true.
And yet (having been a manager), I also understand the team manager’s desire to make sure everyone is fully dedicated to trying to make the deadline happen. Alas, there’s no real way to tell whether managerial exhortation will make a difference in the outcome. And it sends a subtle message to the engineers that they might not be trying as hard as they could.
Fortunately for this team’s manager, his own commitment to the team is clear to them, so they accept his exhortations as unintended humor rather than a clueless insult. That’s not to say such exhortations wouldn’t make a difference when given to a marginal team (managing marginal teams requires a different approach, but that’s a whole separate discussion).
What, if any, is the point of my story? First, I wanted to stress the importance of being honest with engineers. I once worked with a guy who told me that employees are like children, and you should only tell them things that will make them happy. But most people know when they’re being told a story. Second, most grown-up engineers can accept an arbitrary choice by management when the options appear to be equally good. But demonstrably bad choices make them crazy.
Finally, my points apply to other smart, committed people in your organization. Being honest and clear about the rationale behind choices affecting them is part of the key to great performance by your employees and your company.
I haven’t forgotten my promise in last month’s column to write more about “reusable” code and the future of programming. Disappointed at the delay? Exhort me at mduffy@northbaybiz.com.
