To tell the truth

 I cannot tell a lie—catchy phrase, but a children’s tale. Everybody lies from time to time. Sometimes it’s strategically leaving out details. Sometimes it’s not saying how you truly feel. Sometimes it’s an out-and-out fabrication. No matter the reason or circumstance—lying is deception, pure and simple.

Some might rationalize this behavior as “white lies,” but it amounts to the same thing: dishonesty. If someone catches me lying, no matter how slight, I fess up immediately, sincerely, and remorsefully. When I was a kid, I would perpetuate and cover up the deception. But I’ve since learned that covering it up is far more damaging than the original offense. Most people, including me, aren’t lying to offend anyone; our motivation is pure expediency.

Therein lies the core truth: deception is basically a quick and dirty way to avoid a problem. How is this relevant to software development? Because by focusing on “when” and “why” you or your team lie, you can pinpoint everything from quality issues to retention troubles to increased productivity.

Suffer from delusions

Lying is one of a handful of valuable process canaries that can warn you of trouble. Why? Because lying, cycle time, work in progress, and irreplaceable people hide problems. Long cycle times and large amounts of work in progress hide workflow difficulties. Irreplaceable people hide tool, training, and repeatability problems. Lying can hide just about anything. Scrutinizing these process canaries exposes the problems and enables improvement.

Eric Aside I write about each of these process canaries in other columns: Lean: More than good pastrami, and Go with the flow—Retention and turnover. As for the five whys, like Lean, that concept comes from Toyota.

The key is getting to the root cause of the lie. One of the best ways to do this is to apply “The five whys”—that is, ask “why” five times:

• Why you are lying? What pain are you hiding from?
• Why hide from that pain? What’s the danger?
• Why would that happen? Is there a way to mitigate the danger?
• Why aren’t you mitigating the danger already? What actions do you need to take?
• Why are you just sitting there? Act!

To practice applying these ideas, let’s go over some common examples of lying at work. We’ll apply the five whys to uncover the root cause and discuss how to fix it. Here are our foul foursome of falsehoods:

• Perverting the meaning of the word “Done”
• Weaseling out of a tough review message
• Face-lifting progress reports for your clients and boss
• Denying rumors about a reorganization

Put a fork in me

Say your dev team is supposed to finish up feature development on Monday. On Monday, you go through the team and everyone says, “I’m done.” Later, you find that more than half the features are full of bugs and a quarter don’t handle error conditions, accessibility, or stress. You could ask, “Why does my team stink?” But the better question is, “Why did my team lie?” Let’s ask the five whys:

• Why did my team lie about being done; what are they hiding from? They had a deadline to meet, and not meeting it would drop their standing within the team. The criterion for meeting the deadline was simply saying they were done.
• Why just say you’re done and not mean it—what’s the danger? No one wants to look bad. Unfortunately, there was no personal danger to saying, “I’m done.” So why wouldn’t they lie? The danger was to the team. That’s the real problem.
• Why would that happen; can you mitigate it? There was no verifiable team definition for “done.” This opened the door to deception. To mitigate it, you need a clear definition, accepted by the team, with an objective means of verifying it has been met.
• Why don’t you have a clear definition of “done”? What more do you need? When you agree on a definition and means of verification, you need to put the tools in place. Say the definition is 60% unit test coverage with 95% of tests passing, along with a three-peer code inspection that finds 80% of the bugs. Now you need to add code coverage and a test harness to your build for the unit tests, as well as an inspection process with the appropriate time scheduled for the inspectors and inspections.
• Why are you sitting there? Most of what you need is in Toolbox—aside from the nerve to challenge the meaning of “done” in the first place. The key is to focus on the cause of the deception, and then rectify the root of the problem.

Eric Aside Toolbox is a Microsoft internal repository for shared tools and code. It holds tools that measure code coverage, run unit tests, and even calculate bug yields for code inspections. Many of these internal tools make their way into Visual Studio, Office Online Templates, and other shipping products.

Give me a straight answer

You manage a 4.0 performer you really value, and you’ve told her so. Your division runs a calibration meeting, and your 4.0 performer drops to a 3.5 relative to her peers in the division. It’s easy to say to your employee, “Well, I thought you deserved a 4.0, but as you know, the review system is relative and I can’t always give you the rating you deserve.”

You’re lying, not because what you are saying isn’t true, but because you’re leaving out your role in the process. Again, let’s cover the five whys:

• Why leave out your responsibility; what are you hiding from? You like the employee and don’t want to be blamed.
• Why hide from blame; what’s the danger? Your employee might not like you and may leave the team.
• Why would that happen; can you mitigate it? You are the messenger, your employee feels helpless, and you are no help. You can mitigate the impact by telling your employee how to get the review score she wants.
• Why aren’t you already telling her; what more do you need? You need to know why she got the 3.5 instead of the people who were awarded 4.0.

Eric Aside The process around differentiated pay based on performance is a common source of complaints across the high technology industry. Like the numerical rating system, we’ve changed the process many times at Microsoft, but it’s always been about comparing your work to the work of others doing the same job at the same level of responsibility. What managers should always do is understand and clearly articulate how their employees can improve to compare more favorably.

• Why are you sitting there? Find out what differentiated the 4.0 from the 3.5 performers, and then tell your employee. She’ll have clear guidance on how to improve and be in control of that improvement. Sure, she’ll still be unhappy, but at least you helped her and she can do something about it.

Lipstick on a pig

Your team is falling behind on the schedule. You’ve got a ton of bugs and can’t keep up. Your clients and boss demand to know the status. Instead of a fair representation, you paint a rosy picture in the hope that your team will be left alone long enough to catch up. Aside from feeling bad about being a gutless slimeball, what should you do? Here are the five whys:

• Why the desperate move; what are you hiding from? You don’t want to look bad or have others interfere.
• Why hide from blame; what’s the danger? You’re afraid your project will get cut or transferred to someone else because of your perceived incompetence.
• Why would that happen; can you mitigate it? If your clients and boss get blind-sided by your team slipping, they won’t trust you to take care of it. You can mitigate the problem by being transparent so that no one gets surprised, and by having a solid plan to get on track, which earns you the confidence of your clients and boss.
• Why aren’t you already transparent; what more do you need? It’s a ton of work to constantly collect status from your team and post it or send e-mail. Instead, post your schedule and bug data directly on your SharePoint site, warts and all. Have your team update it directly, right there for the world to see. Use charts to make progress (or lack thereof) obvious. When it’s posted, point your team to it. Everyone will get the picture, and you’ll be able to drive a plan to get on track.
• Why are you sitting there? None of this is hard. Transparency drives the right behavior. It also drives trust, which really is the key asset to being successful.

Look at all these rumors

Rumors are flying around about another reorg. Your PUM has told you to keep it quiet; but meanwhile, your team is getting randomized. Naturally, when the topic comes up at your team meeting, you deny any knowledge of the reorg; instead, you remind folks of the evil of rumors and that the team needs to focus on their deliverables. However, you are overcome with guilt, dreading the day when your whole team realizes that you lied to their faces.

Eric Aside A Product Unit Manager (PUM) is the first level of multidisciplinary management at Microsoft. PUMs are typically responsible for individual products, such as Excel, that are part of larger product lines, such as Office. PUMs might also be responsible for significant components of larger products, such as DirectX for Windows. Reorganizations, also known as reorgs, typically start at the top levels of management and slowly work their way down over the following 9 to 18 months. I wrote more about reorgs in my column How I learned to stop worrying and love reorgs. PUMs are becoming a rare species at Microsoft as the company moves toward a functional organizational structure, as I describe in Are we functional?.

• Why deny the rumors; what are you hiding from? Basically, your boss told you to deny them. You don’t want your team randomized any more than your boss does.
• Why worry about randomization; what’s the danger? You’re concerned your team will get so caught up in the rumors that they’ll fail to meet their commitments. In addition, some team members might even leave the group for fear of unwanted changes.
• Why would that happen; can you mitigate it? Most team members, particularly the senior ones, know how bad reorgs can sometimes get. However, no one (including you) knows if the reorg will really happen or how a reorg will actually turn out. So your team’s concerns are without a strong base in fact.
• Why is your team still taking the rumors seriously; what more can you do? In this case, the problem lies squarely with you. You are taking the rumors too seriously, hiding what you know from your team. You should know by now that only roughly one in three planned reorgs actually happens.
• Why are you sitting there? The solution is simple and obvious here: tell the truth. “Yeah, I’ve heard lots of rumors too. We talk about them in our staff meetings. However, the bottom line is that no one knows whether or not there really will be a reorg until it actually happens. Most planned reorgs don’t happen, and we’re going to look pretty foolish missing our commitments because we were daydreaming.”

I want the truth

I make no judgments about whether or not people should always tell the truth. To do so would be hypocritical and lead to awkward situations when my mother-in-law asks what I think about her decorating.

However, we all work for the same company. You shouldn’t have to lie to your coworkers about business issues. Lying hides problems that need exposure. If you’re feeling the need to lie, ask yourself why. Then ask again until you resolve what the real problem is. People wonder about how they can deliver on the fourth pillar of Trustworthy Computing, “Business Integrity.” Well, now you know.