Friday, November 5, 2010

Goal vs Task

I met a friend last night out at a restaurant he'd never been to. To tell him where to go, I said, "from your office, walk down Boylston until you hit Dartmouth, and make a right. Then walk down Dartmouth and it'll be on your right." This was a mistake. You see, my friend wasn't coming from his office; he ran an errand on the way and all of a sudden my directions weren't very helpful. What I should have said was, "it's at the corner of Dartmouth and Clarendon." That way, no matter where he was, he could figure out the best way to get there. I told him what to do, not what my goal was.

This applies to testing, too. When the product manager asks me, "can you please run a performance test in configuration foo?", that's telling me what to do. It might be right, or I might get some element of it wrong and basically waste the test (and who has time to waste!). If instead, the product manager wants to "run a performance test to update this analyst with the amazing benefits of our new feature foo", that's telling me what you're trying to accomplish. With that I now know to run the exact same test as I did the last time we published results for that analyst - same data sets, same hardware, same system configuration - with the exception that I'll make sure feature foo is enabled. Because I understand what the product manager was seeking to accomplish, I'm much more likely to provide useful test results.

Don't tell me what you want to do. Tell me what you're trying to accomplish.

I'm much more likely to do the right thing, if I understand the end goal. So if I hear something that sounds like a task to me - that sounds like telling me what to do - I'll probably respond with something like, "Just so I make sure I get the information you want, can you tell me about what we're going to do with the results?" You save yourself a lot of time and test repetition that way.

1 comment:

  1. You have it so correct. Telling me what to do will seldom get done what you want to do. It also ignores the skills I was hired for and reduces the excuse for the salary I command. Communication in the since of what to do is wrong sided, it forces managers to be the expert at technology rather than experts on getting teams of people to focus on a completing a goal.

    You talk about testing, but this is true for all departments within an organization. When managers try and figure out what needs to be done, they do harm to that organization. Not only do they needlessly obfuscate the intent of the task being done. They decrease motivation by decreasing the value of the role we play within a company.

    By communicating intent rather than how, managers not only communicate what is really important and why, they allow us the ability to focus at what we are good at. It also allows them to focus what they are good at. Once we are focusing on the “what” and “why” we can better use our talents to achieve those goals.

    As a secondary benefit of us being able to focus on what and why is it frees management up. If management is allowed to think in more strategic terms focusing on goal rather than the how, they can more efficiently handle product schedules, planning, and team engagement. Managers get to be the commanders, sergeants, and generals of our businesses.