I wrote last month about winning arguments in IT. Earlier this week, Phil Haack asked a question (through Twitter) about things he could do to help convince a company to create an in-house QA department. Well, it turns out that I did exactly that at XanGo—successfully pushed for and oversaw the installation of an in-house QA department. I thought it might be a useful follow-up to the previous post to use this as an example of how I "won" that argument.

Concentrate on What is Best for the Company

This is the key, the whole key and nothing but the key to winning corporate arguments. You should approach any problem from this perspective. In this case, I have seen what software development looks like with a competent QA team and I wanted that again. Simple developer testing was leaving holes and we didn't have a consistent deployment model. I was sure that having an in-house QA team would benefit the company.

Now, since I was the Software Development Manager, instantiating a QA team was likely out of the scope of my responsibilities. Fortunately, I had a good relationship with my boss and he was the functional IT Director. It was well within his scope. This gave me my first temptation: the desire to expand my personal empire by creating a "QA Team" within my department. After all, it was my idea, it would take a lot of effort on my part to bring about, and QA is associated with development, right?

Tempting as it is, though, it would definitely not be to the company's benefit. A QA team should have as much power as they can get because they are the last rational review before stuff goes into production. What that means in practical terms is that they should be a first-class IT member. If other departments can override QA, you are headed for a lot of pain.

Which is when I realized that what I had to do first is marshal all the reasons I could think of that an in-house QA team would benefit XanGo. This is probably really what Phil was looking for. It's easy to come up with reasons it'd be good from your own perspective. It's a lot harder to broaden that perspective to the company as a whole.

Here's what a list of personal benefits might look like:

  1. Backstop development so that buggy code doesn't hit production.
  2. Help train developers by pointing out errors early enough that it is still in the mental cache of the developer who created it.
  3. Give me a blame-shield if something broke.


Here's some things that are more useful from the company's perspective:

  1. Backstop development so that buggy code doesn't hit production.
  2. Help train developers by providing timely feedback.
  3. Ensure that customers don't encounter broken processes.
  4. Ensure that employee bug reports and feature requests are tracked, prioritized, and scheduled.
  5. Develop and own a formal build/deploy process that is repeatable and automated.
  6. Increase executive confidence that software releases do the things they are promising people it does.
  7. Help identify training opportunities for development.
  8. Help identify training opportunities for non-development staff.
  9. Create a manager who can concentrate on identifying people with QA skills and provide a career path for them.
  10. We have a Software Development Manager who knows what a good QA team looks like and how to create one and we can easily leverage his expertise without bringing in expensive consultants.

This list was my external list of arguments. Which ones I'd present depended heavily on a given audience. With executives, for example, I'd start with #3, glide through #4, #1 and #7 and then slam into #6. I'd pause there and ask if there was interest. If I had their interest (and I guarantee that I did), I could cover the other points in more detail--generally in a follow-up, formal meeting.

Show Me the Money

Reason is all well and good, but without something concrete and measurable, we're still in the realm of faith. Yeah, it makes sense, but it's still just a framework of belief. Now, there's nothing wrong with belief and sometimes you have to have a holy war in order to keep everyone pulling the same direction. But proof is better so find it whenever you can.

The only proof that counts in business is money. The closer the money is to the company, the better. In other words, find examples that people can relate to. Real examples. I hate that I have to stipulate "Real", but unfortunately, I do. Too often process advocates go looking for best (or worst) case examples or even pull them out of their hat. I've gotten to the point where if it didn't happen internally, I'll check sources. I've learned to derive a certain glee from demolishing someone who was, uh, less than careful. Be aware that people like me are out there and nothing will tank you faster than being shown to be faking your proof. You stand to lose more than simply the argument when that happens.

The best source for examples are things that happened in your company. In the case of XanGo, I was able to track back the cost of some bugs that happened there. A bug doesn't have to tank the company to impose a cost. It is always good policy to do a complete autopsy of significant bugs that hit production. Don't be satisfied with simply fixing the error. Dig as deeply as you can. That's just good practice. In this case, it also let me attach a dollar figure to bugs that actually had hit production despite our best vigilance in development. Adding a reasonable cost-benefit is almost like magic--it clears barriers away like they're made of tissue paper.

Don't mistake, though, a cost-benefit list isn't going to do you any good if you cannot articulate the reasons it will work the way you predict. A money-based analysis that isn't accompanied by solid reasons that you can articulate clearly isn't going to work any better than having reasons without a money-based analysis. Which is to say that it might work, but you're essentially rolling the dice. I prefer not to dice with my career.

More Than Winning

In addition to the above, I made a couple resolutions to myself. These are things that I knew from experience were important in helping a QA department work but that are easy to overlook from the development side of the fence.

  1. The eventual QA team should be at least as high up on the IT totem pole as my team. They would need all the power they could get when crunch time comes and they're still finding bugs. It is the unfortunate reality in business that the ones who had the code last tend to be seen as the barrier to making a deadline.
  2. Educate as many people as possible that QA is a wholly different skill set from development. A skill set, by the way, that is rarer (and hence more valuable). This includes making sure that the eventual QA manager (who I would have a part in interviewing) believed the same way. Too often, companies use their QA department as a back-door to a development career. While this is flattering to developers because it means they are the final product (i.e. the pinnacle, end-point, and better than), it is also a recipe for tragedy because the skill sets aren't simply unrelated--they are, to an extent, opposed.
  3. Resolve to give the QA team my support in any future dust-ups. Dust-ups that are, by the way, inevitable. Developers are going to resent having bugs found by someone not them. They aren't going to like that they didn't actually reach a deadline they busted hump to hit. Further, too often when things go wrong, people start whacking around with the blame stick and they'll start in the QA department. It's really easy to keep a low profile when that happens because you want to avoid getting whacked yourself. It is, nonetheless, a bad idea to give in to this cowardice.

Now, all these things share a common feature: they're all things that require developer pain for the benefit of the QA team. Each one is also for the benefit of the company. My biggest point in this and the previous post is that concentrating on what is best for the company is most effective when it is sincere. We shouldn't be merely willing to do what is best for the company when it means pain for us (and possibly benefit for someone else), we should actively hunt down that pain with the intent of embracing it.

Having a QA department actually makes my job as Software Development Manager harder. It means imposing discipline, slowing down production, formalizing development processes, and giving some of my current corporate power to someone not me. It meant inviting another manager into my department who is at least as high on the corporate ladder as I am and who won't always agree with me.

That's a lot of downside to implement something that would be a lot of extra work and take some of my personal corporate political capital to make happen. The meager personal benefit list above doesn't really stack up well to the short term downside. The only reason I took it on is because I knew that doing so was in the best interest of the company and I knew that I could make that case in terms that others would understand.