Thursday, June 16, 2011

Not a Team Player

What follows is a rant directed at the "engineering is not the business" types. Consider yourselves warned!

There is a strong school of thought running through engineering and particularly through testing that goes like this:
"Engineering is not the business. Engineering cannot possibly know what the business knows. Therefore engineering should not make any decision that could possibly be considered a business decision. This includes any and all market-related decisions, such as whether a product is ready for release, whether a defect is bad enough to warrant fixing, or whether a feature as described is sufficient to provide value."

There is a kernel of truth here. It's true that creating a product is a team effort and that each part of the team - marketing, sales, finance, engineering, support, etc. - understands only part of the picture. No one team member can make a fully-informed decision about whether a product is ready for release, or how important a defect truly is.

The problem comes when this concept is taken too far. When it morphs from "I cannot make this decision alone" to "I cannot make this decision alone so I will not express any opinion," then we have a real problem. We have a failure to be a useful member of the team. For you see, just like you the engineer cannot make the decision alone, the product manager also cannot make the decision alone. The marketing manager cannot make the decision alone. The CEO cannot make the decision alone. Every member of the team needs input and opinions from every other member of the team.

Statements like these exemplify the abdication of responsibility:
  • "I can't estimate this test effort. It's entirely dependent on what I find and what you want to do with the information."
  • "I don't know what the priority of this bug is. That's a business decision."
  • "Well, I know the trade show is in a week, but I don't know if we need to show the new version for it. Engineering should say if it's ready."
Every one of these statements is an explicit refusal to provide an opinion. It is a refusal to contribute to a decision. It's a refusal to be an active, contributing member the team, and it creates a false dichotomy, a we/they relationship that is completely unnecessary.

There is a large gulf between refusing to provide an opinion and being the sole decision maker, and the proper place for a team member - a tester, a developer, a marketing manager, a product manager - is in the middle of that gulf. No, the developer should not willy-nilly refuse to provide a build for release because "it's not ready yet" when the rest of the team thinks it is ready. But also no, the tester should not refuse to say, "I think this bug is really bad and we should hold the release for it because of X, Y, and Z." (generally replacing it with, "Here's what I found. You decide.") Both extremes are a discredit to their professions.

So be a member of the team who actually provides value. Don't be afraid to offer opinions. It's completely acceptable to characterize them as opinions, but use your voice. You're being paid to be the best-informed person on the team in some area, and part of what you're being paid for is to use that expertise to express opinions and explain circumstances and consequences.

No more excuses. Time to step up and embrace your membership in a team - the purpose, the responsibility, and yes, even the decisions.

End rant.

2 comments:

  1. I couldn't agree more.

    In fact, I was beating my head against the wall yesterday when I read an article about testers not being responsible for quality because they don't make decisions like when to launch or what bugs to fix.

    It takes a village to build quality software.

    ReplyDelete
  2. Nice post...no more excuses and no more blame games!

    Kk

    ReplyDelete