Quality Assurance Manager. Senior Developer. Test Manager. Think you know what those titles mean? Are they mutually exclusive? If not, where do they overlap? Which one "owns" Quality? An important step in perfecting the software development process is negotiating and understanding the responsibilities of every team member. In this column, Elisabeth Hendrickson talks about unwrapping the responsibilities beneath the job titles.
Several years ago, I was having one of those difficult conversations with a manager. You know the kind of conversation I mean. A shift-uncomfortably-in-your-chair-and-hope-the-pain-is-over-quickly conversation, something like a visit to the dentist.
He was concerned about bugs found after the software was released. So was I. He was in charge of all of engineering. I was in charge of something called "quality assurance," a term we'd never really defined in the context of this company and my role. Not defining the term when I was hired was my first mistake. As the intensity of the conversation escalated and my manager became more visibly agitated by my responses about how we released the software in its current state, I finally realized what was going on.
"You don't really think I own quality, do you?" I asked.
"If you don't, who does?" he countered.
Oh dear, I thought. I just stared at him. I wanted to say, "If I own quality, then let me determine which bugs get fixed. Let me decide under what circumstances we'll slip the schedule to produce a better product. Let me also own the requirements process because we end up doing one heck of a lot of rework around here." But I knew better. He wanted me to own quality but not the release schedules, requirements process, or engineering decisions: an impossible responsibility. Unfortunately, he seemed to think I'd signed on as the owner of quality because I'd accepted the job title.
So instead of yelling, I said as gently as I could, "Just because I have 'quality' in my title doesn't mean I personally own quality. We're all responsible for the level of quality of the software." He settled down a little, became reflective. He seemed to understand. At least that's the last time he pointed a finger at one particular group for a bad release. The conversation was a turning point for us.
Others aren't so lucky. I was talking to a test manager the other day facing a similar situation. His organization expects that he'll test everything important. Only no one tells him what's "important." He's supposed to know. Nothing specifies which versions of the operating system will be supported, so he has to guess. (Woe to him if he guesses wrong.) If a new version of a Windows OS is released, his organization expects him to know about it and begin testing their software on it immediately. Yet he's seldom given more than two weeks to test "everything."
The other folks in his organization have interpreted his title, Test Manager, to mean that he manages everything associated with test (except the schedule). They don't understand why he can't "test everything" in the time given. From their perspective, testing everything is his job.
This isn't just about titles; it's about responsibility and accountability. When I ask people what could be done to improve the quality of the software their company produces, many people say, "raise the level of accountability." What they really mean is, "I'm doing my part. Hold the other guy's feet to the fire."Perhaps the real problem is that we don't know what our parts are. We don't have agreement about who's doing what. But we think we do because everyone has standard titles. These titles have become a kind of shorthand. Everyone knows what the Quality Assurance group does, right? We don't explicitly define the scope of responsibility of the groups because we think we already know. Unfortunately, we also often have very different expectations.
A "Senior Developer" doesn't have "Test" in her title. So should she be responsible for testing to make sure the changes she just made in a shared piece of code will work with the other pieces of code? If you ask the testers, they'll probably say, "Yes! The developer is responsible for making sure that her code plays nicely with others." If you ask the developer, she's more likely to say, "I'm not a tester. I made sure my stuff works; it's up to someone else to make sure everything works together."
Some organizations solve the problem of no one taking responsibility by creating positions that bridge the gap. A new job title. Someone who can truly own that piece of the puzzle. When it works, it's an excellent solution. Unfortunately, sometimes it becomes a crutch when other members of the organization shift more and more of their work onto the new bridge organization. Maintenance engineers become responsible for almost all bug fixes so the other programmers can focus exclusively on new code development. Integration engineers become responsible for unit testing. External beta testers become the sole source of use case testing. Will forming a new group work in your situation? Maybe. Maybe not.
Perhaps the most powerful question anyone can ask is, "If our development process worked really well, what would it look like?" In answering that question, and in combining answers from many different areas of the company, you can get a clearer picture of where reality isn't meeting expectations. Then you can work to address the difference between reality and the idealized process. If their expectations are unreasonable, you can negotiate.
So what's in a name? There may be a bushel of expectations and a barrel of responsibilities, not all of which you might think you signed on for when you took the title. Make the expectations and the responsibilities explicit. After all, your title might not mean what you think it means.
