TEXT TRANSCRIPT: 11 September 2001
Copyright 2001 Quality Plus Technologies and Carol Dekkers. All rights reserved.

Announcer: Welcome to Quality Plus e-Talk with Carol Dekkers, sponsored by StickyMinds.com, your online information resource for building better software.

Carol Dekkers: Hello, and welcome to Quality Plus e-Talk with Carol Dekkers. I'm Carol Dekkers, president of Quality Plus Technologies, Inc., and we are acknowledged leaders and providers of professional software measurement and function point analysis consulting services. Quite a specialty. Today I'm here with Johanna Rothman, whom many of you may know from Internet listening, from many of the shows that we've done in the past. This is our first, premiere show of this new season. And I'd like to welcome Johanna to the show. Welcome, Johanna.

Johanna Rothman: Hello, Carol. It's nice to be here.

Carol: Johanna observes and consults on managing high technology product development, looking for the leverage points that will make her clients more successful. And today we're going to talk about something that I think a lot of people have had challenges with, especially in our new economy, where a lot of people get moved from job to job, and that's the topic: What Do They Really Pay You to Do? And Johanna's written a number of articles, and we're going to walk through those, and really find out what it is that they pay us, in software development, to do-what they pay us in testing to do-and really, how can we be more successful in our jobs? What I'd like to do, Johanna, in the first five-minute segment here, is just go over a little bit about what we're going to talk about, kind of set the stage, so to speak, and then when we get back from the first break, we'll actually get right into it. How does that sound?

Johanna: Sounds good.

Carol: Okay. The article that you just wrote, which is phenomenal, was in the September/October 2001 issue of STQE magazine. Correct?

Johanna: That's right.

Carol: Can you just give me a little bit of an idea, kind of maybe a 30-second abstract, of what do you mean by "what do they pay you to do?"

Johanna: Well, I've been to a lot of conferences, and I've met a lot of people. And people are always saying to me, "But I really want to do this thing, but my manager doesn't want me to. I thought it was part of my job description, but my manager says we have no time. I see a real crying need for this in our organization, and my manager says, 'No, we can't do that.'" And so I thought, you know, this is crazy. These people really want to do a good job. But their personal mission is mismatched with what their company wants them to do. So that's… And I said, okay, I'd better write about this, so people can figure out, do I fit into this category, is there something I could be doing differently, to either realign my mission with my company wants, or make my company see that there's something else that I could be doing?

Carol: This sounds like it extends beyond just software. And I know that you wrote the article primarily for software developers, for software testers. But from what you've said so far, it sounds like it could be anybody in any job, no matter what they do.

Johanna: Well, it actually is for that. The article is aimed at testers, but I see this a lot with project managers. Project managers who want to see their product go from point A to point B, and they say, okay, I know I have to have this release now, and that release in six months, and another release in a year and a half. And they're ready to lay the groundwork for that, in whatever release they're doing, not realizing that by laying the groundwork, they're actually going to push the release date out, which will make the eventual, final product, the thing that they want to actually accomplish, very, very difficult to accomplish. So I see this a lot with project managers. I see it a lot in middle managers too. Middle managers get this from both sides. Their employees want them to do one thing, and their senior managers want them to do something else.

Carol: And we will be back with more of Johanna Rothman and Quality Plus e-Talk! with Carol Dekkers after these short messages. Please stay tuned.

Welcome to Quality Plus e-Talk! with Carol Dekkers. I'm Carol Dekkers, president of Quality Plus Technologies, Inc., an acknowledged leader and provider of professional software measurement and function point analysis services. We cater to, and we look after the people who actually build software. We make sure that they help others build software better, we help users, we help people who are really challenged with building better software. And we'd like to thank our sponsor, StickyMinds.com, for helping out with that, with our sponsorship. Today, we've been talking to Johanna Rothman, who is a specialist, a private consultant, who specializes in going into organizations and making them work better. Our forte is really in the software development area. And that's the theme of this set of season's shows, is really on how to help make software better. How to build it better, how to work with it better, how to test it better. The whole gamut. So if you're new to the show, if it's the first time you're listening through the Internet, we'd like to welcome you. And I'd like to get back to talking to Johanna Rothman, who has recently written a paper in STQE magazine, called "What Do They Pay You to Do?" Now, before the break, before our first break, we were talking a little bit about what do you mean by "what they pay you to do." And we mentioned that Johanna has written the article primarily for people who do software testing. When software's ready to actually be released, or far down the line, when code is first started. And even before that, testers get involved to make sure that software is going to run the way it's supposed to. Now, Johanna has been in a lot of organizations, and observes a lot of things. And can I just get you to kind of paraphrase again what you were talking about, about what is the challenge of people not knowing what they're paid to do?

Johanna: You have a mismatch between what you want to do and what your organization wants you to do. And the larger the mismatch, the less work you're going to do that's of value to the organization. And especially now with this economy, the last thing you want to do is work that's not valuable to the organization. That leads directly to being fired and being laid off. So you want to make sure that the work you're doing is perceived as valuable. That's why you want to do work that the company pays you to do. On the other hand, you can't get away from the fact that we're human beings, that we have brains, and we're being paid to use our brains. So how do you use your brain to say, "I see a hole over here. There's something I want to be able to do that looks better. How do I correlate that, how do I realign that, with what my company pays me to do?"

Carol: And would you say there's a bit of a misalignment between thinking in the box and thinking outside of the box, as has been mentioned? Is it a problem that when you have a job description…Say you have a job description that you are a programmer level 1 or a programmer level 2, or a software tester level 1. Doesn't that imply, in and of itself, what you should be doing?

Johanna: It certainly does imply part of what you should be doing. I see a lot of job descriptions, which is why I'm writing a book about hiring people. But the problem with job descriptions is that they're either so vague as to be useless, or they're a laundry list of technical skills that have absolutely not much to do with how people do their jobs. So I've seen a lot of job descriptions that aren't very helpful to people. Certainly not the people doing the jobs and not their peers, not their managers. So one of the things that you want to look at is, if you have, if you're lucky enough at least to have a job description, even if it is a laundry list or something big, is does it point you in the right direction? Do you at least know that if you're a developer, does your boss actually want you to find the defects before you check the code in, and before the testers get to it? If you're a tester, are you supposed to actually plan your testing first, or are you encouraged to do more exploratory testing, and then do some planning? What are the things that your organization feels most comfortable with, and does what they feel comfortable with match what you need to be able to do to be successful? See, there's a potential for a lot of mismatches all along the way. But let's at least look for what's in the job description, versus what you need to do to be successful in the organization.

Carol: Sometimes it sounds like you may get a job description that on paper says you're supposed to do all these things, and this is probably true at any job. But then on the job, in actuality, in practice, your job may not be anything like what your job description actually says.

Johanna: Oh, absolutely. And all of you who are QA managers, or QE managers, Quality Assurance or Quality Engineering managers out there, you're probably wondering exactly the same thing. I think one of the reasons that I no longer work inside organizations is I was working as a QA manager, that was my title, Quality Assurance, and I thought it was absolutely my job to be gathering metrics, to be suggesting areas for process improvement, to be doing things that would make a difference further down the line. Not so much necessarily in projects that were already almost complete, but certainly in projects down the line. And the first time I came up with a metrics memo, my management came to me and said, "Never give us a metrics memo again. If we don't know about it, we can't be sued." And a lot of senior management seem to think that's an acceptable way to run a company. It wasn't for me, so I left. But it is for other people. So if that doesn't bother you, that's okay. But if it does bother you, then you have to figure out "how do I realign what my company says they want me to do in the job description, versus what they actually want me to do in person, on the job every day?"

Carol: That's got to be a challenge, particularly if you're in a position where you see things that have to be done differently, or you can see an easier way or you can see a better way… I think what you're saying is that that's not always appreciated.

Johanna: Well, it's not always appreciated. And that's not to say that your company, if they don't appreciate you doing potentially things that would improve things, that they're bad people and that they're a bad company. Maybe they're so caught up in the day to day existence of "how do we increase our revenue, how do we make more sales, how do we service our current customers," that they really can't think, they just don't have any more brain waves left to be thinking about something else. That's a possibility. There are other possibilities that aren't nearly as generous. And you have to decide if that's what's happening. Are these people just jerks that you don't want to work with? Or is there something in between, where maybe you're working for someone who is so focused on the bottom line, but their supervisors are not necessarily focused on the bottom line? I see that happening a lot to developers and testers. People doing technical work, specifically technical work, who think that they could improve things if they just had an extra five minutes, or an extra day here or there. And their management says, "No, we're not going to do it that way." What do you do then? And I think then you sit down and have a talk with your manager and say, "I can see that there are other things we could do here. There are other things we can improve. If we did inspections and reviews, we could do this thing. If we tested a little differently, we could do that thing. What do you say? Can we do a little experiment to find out?" So if you give your manager options, he or she is much more likely to consider it than if you say, "Well, I'm the tester here" or "I'm the developer here. I know what's best." Once you've put yourself in the only position of knowing what's best, you tend to increase resistance to your ideas from other people. And that doesn't help you get anything done.

Carol: Now, it really sound like you're talking about communication, and effective dialogue. That you have to have a dialogue set up. But I can just kind of hear some of our audience saying, "Well, I'm in a position that I don't really like," or "I'm doing my job the best way that I know, or have been trained to do. And we've got layoffs, and I don't want to make the wrong step by going and talking to my manager." What kind of advice would you give somebody like that?

Johanna: Well, if it's not the right time, then don't do it. You have to be confident in where you are, in your position in your company. If your company's going through layoffs, the last thing they're going to think about is huge process improvement. Now, if you had a specific idea, something small that they could see a return on their investment very quickly, that would be probably useful to do. And especially if you could describe it quickly. I think part of it is, sometimes we get very bogged down in how do we sell our process improvement ideas, or how do we sell this great new thing, and we spend all this time selling, when in reality, we could spend ten seconds selling something and then say, "Do you like that? Should I go do it?" So you know what kind of a manger you're talking to. Are you talking to someone who wants to see things written down first, or are you talking to someone that you're going to catch in the elevator for thirty seconds, and they're going to say, "Yeah, go ahead, do that." So, what kind of a person are you talking to? Because if you try and find… If you try and get thirty seconds of the person who needs to see things written down and to see all of the arguments for and against, if you catch them in an elevator for thirty seconds, they're going to say, "Are you out of your mind?" And they're going to just shut you down. But if you give people the information they want, in a way that they want it, then they're much more likely to hear you. If you're personally concerned about losing your job, then don't do anything. The first thing you have to do is say, "What do I need to do to put food on the table and keep my kids in school" and whatever it is that you're doing. Absolutely. If you have a little flexibility, if you're not under the gun, if you think that your company could benefit from doing just a little bit something different, it's worth making the time to figure out "How do I talk to my manager? What's the right way?" And then, "What does that person need to see from me? Do they need to see the big picture? Do they need to see a whole lot of data supporting my argument?"

Carol: Right. Now it sounds like you really need to have good communication skills. And before the show, we were talking a little bit about your notion of something called a "mission." And maybe you can expand a little bit on that. Does everybody have one? You were talking a little bit about dangerous missions. And it kind of sounds like walking through a minefield. Maybe you can just expand a little bit on that.

Johanna: Sure. I think that everybody has a mission. Whether your mission is to go to work and do a good job and collect a paycheck and come home, which is a perfectly valid mission, or whether your mission is to create the most fabulous software in the entire world, or if your mission is to find all of the bugs, even the ones that are hiding, that the developers can't find. I mean, it depends on what it is that you do for your mission. But everyone comes to work with some kind of reason for going to work. And you're the only one who knows why it is you come to work. So, what drives you? What makes you want to come to work in the morning? What's the thing that gets you out of bed, that keeps you going? And assuming that it's not just to get a paycheck, because I suspect that even those of us who are cynics, who say, "Well, I just go to collect a paycheck," you actually have another reason for coming to work in the morning. So, what's the thing that drives you? Do I need to stop, Carol?

Carol: Yeah, we do. We're going to go into a break. And thank you for joining us. We'll be back after this short break with more of Johanna Rothman and Quality Plus e-Talk! with Carol Dekkers. Stay tuned.

(Commercial break)

Carol: I'm Carol Dekkers, and you are listening to Quality Plus e-Talk! with Carol Dekkers. With our guest this week, Johanna Rothman, who has been talking about "What is it they really pay you to do?" In a system development or system testing job. Now, before we get back into the questions, and Johanna's article that she has been writing, and the book that she's in the process of, I just want to give you something from our company, from Quality Plus Technologies. I would like to offer any of our listeners the opportunity to have a function point analysis meets the Software Engineering Institute CMMI model. We have a calendar that actually shows that for you. And there's a few months left in the year. So anyone who's interested in the calendar, I'd like you to send me an email at [email protected], and I'd be happy to send that to you. As well, if you have any questions, comments, or anything that you would like to submit in terms of upcoming guest questions, I invite you to do that by going to our e-talk home page, at StickyMinds.com/etalk, and there you'll see past shows, you'll be able to listen live, and you can actually send us comments and concerns and questions for upcoming guests. So Johanna, welcome back to the show.

Johanna: Thank you.

Carol: We were talking about avoiding this mismatch. And I think it's probably even more important today than any other time in history, when the recession's hitting, and when we've got people worried about their jobs, that we're actually doing the jobs that our employers expect us to do. And what they pay us to do. And it really sounds like it's communication issues, but I think it goes deeper than just basic communication. Can you comment on that?

Johanna: Yeah. I think that, as I was saying before the break, there are different things that drive each of us. So it's not just communication with your manager or with your peers. It's sort of knowing what kind of a person are you, and why is it that you come to work every day. You'd asked me before about a dangerous mission. And there actually are at least a couple of dangerous missions. I think if I thought about this for longer than a nanosecond, I'd come up with half a dozen more. But the big ones are when you take on strategic decisions, things that should be business, strategic decisions, and you decide that you have to make those decisions yourself. And the two of them that I came up with are, the first one that's classic for testers and test managers, is when you're responsible for ship decisions. Ship decisions are absolutely a business decision. It's a strategic decision, it has revenue impact. And if you're in an IT organization, where you don't actually ship a product, but you release it to your internal users, it's exactly the same as if you were shipping something for revenue. Because your whole integrity, your organization depends upon you doing the right thing. You can't possibly know what the right thing is if you don't have all the information. If you don't know what customers wanted, you don't know how much revenue is riding on it, you don't know if it needs to be better, and you don't know if it needs to be out now. You just don't know a bunch of that stuff. The other dangerous mission, I think, is something that project managers, and especially senior developers, fall into this trap. And that is being responsible for product direction. I can't tell you how many organizations I've been a part of, where the engineers have set product direction. They've said, "We know the users, and the users want this." Well, they actually don't know the users. And they probably don't know precisely what the users want. I find that a lot of us are really bad at getting requirements. We don't, many of us don't do QFDs, where we have our users rank the kinds of things, the kinds of alternatives that we can give them. Nor do we ask them context-free questions, which allow us to get at requirements in yet a different way.

Carol: Now, you said QFD. Can you just explain that for our listeners?

Johanna: Sure. That's Quality Function Deployment. And that's a way of… If you've ever seen these little houses, with the dark circles and the somewhat dark circles and the open circles, that's where there are these houses where you say, "Here's the kinds of things we can offer you as an alternative. Here's what our competitors do. Rank these, tell us what's most important." And so you end up with a mathematical ranking of what's most important for your customers. And I think that context-free questions first, asking people what problem they want to solve, followed by QFD, is an incredibly powerful requirement solicitation technique, and I think one that too few of us use.

Carol: So we're really talking about getting back down into the software requirements. Actually having a business reason for doing things. And software won't necessarily solve it all. We're going to be back with more of Johanna Rothman, and I'm Carol Dekkers on Quality Plus e-Talk! Stay tuned.

And we're back. I'm Carol Dekkers of Quality Plus Technologies, and this is Quality Plus e-Talk! with Carol Dekkers. We've been talking a lot to Johanna Rothman, this week's guest. And I have to remind people that are listening that Johanna Rothman's session last season was actually one of the most popular. We got outstanding reviews for Johanna's insight, and the fact that she's been sharing a lot of what she sees in organizations, with many people, at no cost, when it's in articles and that type of thing. Johanna also works, and she's offering a new workshop, a management practicum on the 9th to 11th of October in Boston. Isn't that true, Johanna?

Johanna: That's correct. We're hoping that managers of all sorts will come and share what their issues are. Because we can make real-time simulations and real-time experiential learnings happen there.

Carol: And if anyone's interested in signing up for that, or for more information, you can go to Johanna Rothman's Web site, which is jrothman.com. Before we went into break, we were talking about, I just mentioned, that software doesn't always meet these requirements. And I've seen and been in situations where the software developers are blamed. When you have a piece of software that comes out, and people say, "This cost the government…" or "It cost my organization $6 million to build, and it doesn't work like I want it." I'm going to ask what might seem like an obvious question. Do you think it's part of every computer professional's job, what they're paid to do, to verify that these requirements are correct? And point them out at every possible stage? Is that a role that we all have to play?

Johanna: Well, I actually think it is. I know that when I was a developer, and people said to me, "I want you to do this thing," I always said, "Give me twenty seconds on why. Tell me the problem I'm trying to solve." Because if you understand the problem you're trying to solve, it makes understanding the requirements very clear, and then how you implement the requirements is even more clear. Most of the time, sometimes we think we don't have enough time to do that. I think we don't have enough time not to. But I think everyone involved in developing software or testing software needs to understand, where did this requirement come from? And who's going to benefit from this requirement? We have lots and lots of different users of our systems. There are the people who buy the systems, and they could be very sophisticated to very unsophisticated. There are people in our own companies, who we can think of as users of the system, whose lives will change because we've produced this system. And there are people who we don't want to use the system. Right? ATMs are based on the fact that everyone has a password, and if you don't have the password to go with the card, you're not supposed to be able to get in there. So there are people that we want to prevent from using the system. There are people who we want to use the system. And there are other people who are affected by the system in multiple ways. We need to know what does this requirement mean to all of them. It doesn't mean you spend twenty years on a Master's thesis to try and figure this out. But spending a couple of minutes on every new group of features, undertaking ten or fifteen minutes, or going back to the architect and saying, "Tell me why this thing goes here. Explain this to me." A little more understanding at the beginning can lead to a much more superior product, and something that gets done faster in the end.

Carol: So if you uncover, say, that a requirement is wrong, or doesn't look right, and you're not an analyst, and you're in the test stage, I think what you're saying is that it's important for people to point that out. And I can see some people saying, "Well, that's a bit of a danger. That might be stepping outside my job description." What are your thoughts on that?

Johanna: Well, it could be stepping outside your job description. But most of the time, the people in test are supposed to verify that the implementation of the requirements was correct. If they haven't… If they're not… If someone isn't verifying the requirements themselves are correct, you're missing a piece of some testing that needs to get done on that product. If you're concerned about the reaction that people are going to have to you when you say, "Why are we doing this thing?" or "This looks funny to me," there are a couple things you can do. One is, why does it look funny to you? Try and articulate that, in terms of what would it cost the customer to do this? Or I should say the user. Because sometimes our users are different from our customers. What would the user do with this requirement the way it's implemented? Is it a problem? I don't know how many of you have worked on GUIs, but I know that back in the '80s I was working on a GUI system that really stunk. It was terrible. And I was a tester at that point, and I went to my manager, the project manager, and I said, "This is too slow for people to use." And the project manager took a look at me and said, "It is not." And I said, "It is too." This is not evidence of good discussion, right? The "Yes but No but" is fine for two-year-olds, but it doesn't work among adults. So I went back, and I said, what are the five common things that people would want to do with this Windows system? So I listed them, and I said, in the old system, before we had this particular GUI, it took us this many seconds to do these five things. So, and then, I timed it for this new system, and said, and it took two or three times as long to do any one of those things. I brought that back to my manager, and I said, "Here's my problem. It takes so long to do these things. These are the most common things people want. Now what do I do? I see what I think is a problem. And you told me before you didn't think it was a problem. Do you think we can re-evaluate this?" And he said, "Oh, now that I have the data, now I understand where you're coming from." So, it's how you approach it.

Carol: So you made it more than just an opinion. A "he said, she said" type of thing.

Johanna: Right. What are the consequences of this problem? And that's actually… Anyone who finds defects in software and wants to report them, if you can start with the consequences of the problem, you're much more likely to see the problem solved, than if you just say, "I don't like this."

Carol: Right. I think one thing that you've articulated that typically might just go over the heads of some people, is the use of acronyms, that sometimes we use acronyms in software development that other people just may not understand and may not even have the guts to ask. So when you say the word "GUI," well, I can see some of our audience who are users, they may say, "Oh, gooey, does that mean something like sticky? Is it like bread dough?" And when we say "GUI" in system development, that actually stands for G-U-I, which means Graphical User Interface. Which is typically something that you would see on an IBM desktop computer, a computer that you would buy from Radio Shack or Computer City, or Circuit City. It's actually anything that works with a mouse and has a good, friendly user interface. So something that has point and click, and that type of thing, is what we normally refer to as something like a GUI. And, I'm, we didn't rehearse this, Johanna, but I think that's a perfectly illustrative example of how we sometimes can get caught up without even realizing it.

Johanna: Right, and I see this in acronyms all the time. And without you folks looking back at me with your befuddled faces, I can't tell that you don't know what I'm talking about.

Carol: That's the problem with radio. You can't see the people. Now, if you're a test lead or a test manager or a QA manager, and you've got this title, job title, and maybe you've made up your own job title, if you're in a creative organization. What really, how do you find out what you're supposed to do if you don't have a job description?

Johanna: Well, actually, if you don't have a job description, you're in luck. Because then you get to say, "What are the things I think I should be doing, and which of them provide the most value to the organization?" Now, especially you'd ask about test managers or test leads. I think anyone in that position… My favorite mission for being a test manager or test lead is to be able to assess the state of the product under development at any time and report on that state. Now, the nice thing about that is it says I get to test from the very beginning, I get to test everything about the product, right? So I get to test the project plan, the project schedule, the requirements… Now, that doesn't mean I have to do …-style inspections on everything, but I have an opportunity to look at everything. I have an opportunity to figure out how would I test this, assuming I had the time and the schedule, and how do I make time in the schedule? So, for people who are lead testers and test managers, and QA managers, I really like this notion of assessing the state of the product and reporting on it. For those of you who are also QA managers or possibly quality engineering managers, QE managers, you may be able to add a little process improvement there. Assess the state of the process at any time, and work with my peers to improve that. Now, because you have to work with the development managers and the project managers, everyone who's involved in your organization in producing products. You can't work on the process by yourself. You're not the only who uses it. So as long as you understand that you might be facilitating the process improvement, or bringing things to other people's attention for them to work on, that's a fabulous thing to do. For those of you who are project managers, I really like… I think of project managers as sort of… This is going to be a little weird, Carol, bear with me. You know, you're sort of like this chariot, Ben-Hur, but it's not just your chariot, there's everybody's chariot, and you've got your hands on all the reins. You can't pull on anything in particular, because then you're not managing the whole project. But you have to know when do you go to the front of the line, when do you go to the back, when do you leave from the middle, how do you know where everything is at any given time? And of course, as a project manager, you actually can't know that. But you can get close. And the question is how close can you get? And how can you make sure you know where the project is at any time? So there's a… For me, the whole notion of being a technical lead or a manager in an organization is to be able to do some assessment - where am I? To know, where is it I wanted to go? And to see the difference between those two things. And then be able to take steps to solve the problems, the inevitable problems that show up. But not to necessarily make all of the decisions for my part of the organization. Because I don't know enough. There's no way I could know enough.

Carol: And I think that's a really valuable point to make. You mentioned before that you, as a test manager, as a QA manager, have a role. And I think with your example of the chariots, I never really thought about it that way before, but I have this notion of a coliseum, and chariots running all over the place, like "Gladiator" or something like that. I never really thought of projects like that. But I think some of our projects actually are very, very similar to that. I think you mentioned also that it's really a team thing. And when we were talking about a ship date, I think a lot of times ship dates are really contentious issues. Either the marketing manager has said that, you know, this product, this Microsoft Windows XP, JX47, you know, nine million acronyms behind it, is going to be ready on January 1, whether or not it is. And then you get the testers who say, "Well, there's no way we can put it out." And then you get Bill Gates or somebody saying, "It's going out." It seems to be a little bit of a struggle there, particularly with ship dates, particularly with quality assurance people, who want to make sure that they are shipping a good product.

Johanna: Yeah, I think ship dates are the hugest, the biggest source of contention in an organization. When do we know the software's ready to release or not? In fact, I think I wrote a… oh, my release criteria paper, I should say article, isn't out yet, but I gave, I've been giving talks about release criteria at some of the conferences this year. And I think I've posted some of the PowerPoint slides to my Web site, but I can't remember. There are a couple people at Intel who are doing some really nice things about quality release criteria, which is one aspect, I think, of release criteria. For me, release criteria are, you can think of it as a balanced scorecard. What do I need to think about, in order to know whether or not my product is ready to ship? You know, is it just the date? It's probably not just the date, but the date has a huge impact. Is it just the number of defects? Not just, but again, the number and the types of defects have a huge impact. How much testing have we done? Do we actually know enough about this product to know what the risk is of shipping the product? Because there's risk on both sides. There's risk for shipping, and there's risk for not shipping. How do we balance those two? And most of the time, those of us who were not senior managers in organizations don't actually know enough about the risks of not shipping. We only know about the risks of shipping, because we see the defects, we see all those kinds of issues. But especially in the down economy, if you need to make revenue numbers, or if you're in an emerging market, and you have customers clamoring for your software, the worst thing you can do is delay shipment. Now, when you have a well-established product, it's a little bit more of a surprise to me why the ship date is so important, except that there's usually a bunch of Wall Street implications. "Well, the company said they were going to do this thing, and then they didn't." And then the stock goes down. So again… And the stock goes down whether it's good news or bad news, that is completely irrelevant. But the problem is that if your stock is likely to go down because you don't make a ship date, would it be better to ship something and immediately send out a patch release? Or would it be better to wait and have your stock go down? I don't know of a senior executive who's ready to have a stock price go down. I just don't know.

Carol: And it certainly doesn't sound like that is something that we in development are paid to do.

Johanna: We are certainly not paid to do. In fact, we don't even know what the possible consequences are. That's why it's so important, when you take on your personal mission, to understand what are the consequences of me taking this personal mission on? Is it appropriate for me to make these decisions for my company, or am I going to have any way, shape, or form of getting this information that I need to make this decision? And if I can't get the information to make the decision, why should I stand in the way of my company making these decisions? So especially for ship dates, especially for product direction, I don't think it's appropriate for technical staff, and probably not even for middle managers, to be making enough of those decisions by themselves.

Carol: And I know we're just about out of time. It's been great to talk to Johanna Rothman. We've talked about "What is it they really pay you to do?" I think that's been a challenge for people in quality assurance, it's a challenge for people in any walk of life, in any one of your jobs. If you don't have a job description, or you have a job description that is a mismatch with what the organization really wants you to do. And I'd like to thank you, Johanna, for spending this last hour with us and sharing your wisdom and your insights.

Johanna: Thank you. I've really enjoyed it.

Carol: I'd also like to spend a couple minutes just talking about your new book. I'm intrigued, I didn't know that you had a book coming out, and I'm dying to know, in the book, whether you're going to have the worst possible job descriptions you've ever come across.

Johanna: No, I actually wasn't going to. I was afraid people would use the "worst possible job descriptions." But I will have sample job descriptions, and a lot of interview questions. I find a lot of people don't know… They don't know how to interview potential candidates. And of course, candidates can use this book also. If you're looking for a job and you want to know, what kind of a manager am I interviewing here, you can ask them the same kinds of questions. So it should be useful on both sides.

Carol: What is the title of your book?

Johanna: The working title is Hiring Technical People. It's about how do you prepare for hiring people. What's your strategy for bringing people into the organization? Do you need a certain kind of person? Will any developer do? And the answer is, of course not. Not any developer or any tester will do. But how do you know what kinds of people you need and when? And then it walks you through how do you set up… how do you actually write a job description? Writing ads, all that stuff.

Carol: And we'll be back to finish up with Johanna Rothman on Quality Plus e-Talk! with Carol Dekkers after these short messages. Please stay tuned.

And we're back. I'm Carol Dekkers. And you've been listening to Quality Plus e-Talk! with Carol Dekkers. Our guest this week is Johanna Rothman, who is a senior management consultant, involved in high-tech product development and advising chief information officers and CEOs in major companies on how to build better software and how to make their people work more effectively. Johanna, I think your Hiring Technical People will be a phenomenal book. And do you have a date that you're planning on having that out?

Johanna: No. As soon as possible. I am in the midst of finishing off the final edits, and I… This is one project that I don't know how to plan very well. So, it turns out the testing has gone on a lot longer than I expected. So, but this is not something where I'm bound by a particular date. I want a really good product to get out there.

Carol: Well, somebody needs to set a ship date, I guess.

Johanna: Could be, yes.

Carol: One of the things that Johanna shared with us, that I've realized in the last hour, is that quality software is not an accident. And that we can all, as test managers, QA managers, project managers, users… We can all become more effective by knowing what they pay us to really do. And in doing that, in knowing what they really pay us to do, and doing our jobs, we can really build better software, which is the whole theme of our show and our sponsor, StickyMinds.com. I'd like to tell you a little bit about some upcoming shows that we've got. Next week we have the privilege of bringing back one of our guests, Tom DeMarco, who has written a plethora of books. And his latest book is called Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. I just finished reading Tom DeMarco's book, and besides being a very easy communicator, he is… you don't need any major technical background to understand what Tom DeMarco says. It's a handbook for managers, entrepreneurs, and CEOs. And really, what he's saying is in our economy of working faster, stronger, cheaper, faster, stronger, cheaper, over and over and over, that actually, we haven't planned for slack. And are we really getting more productive by working more hours with less people, or is there really some hidden meaning and some hidden productivity in the slack that used to happen between people, and when we used to have secretaries? Tom uses a very illustrative example of how a secretary used to be shared by several people, and could always hop to whatever it was that somebody needed her to do immediately. Or her or him, I don't want to be sexist here. Whatever they needed to have done, it would be done very quickly. And in our efficiency building economy, we've got that secretary so incredibly planned down to the minute that we wonder why they can't hop to it anymore. So Tom DeMarco's going to be our guest next week. We've always got a series of guests coming up. We've got Ivy Hooks, who has written a book, it's wonderful, called Customer-Centered Products. And it's not specific to software. It's specific to any type of product. So I hope you'll join us for the coming shows. I'd also like you to take a look at our StickyMinds.com e-Talk radio page. And also go out and take a look at my personal company page, www.qualityplustech.com. Until next, I will e-talk to you later. Thanks for joining us.

Copyright 2001 Quality Plus Technologies and Carol Dekkers. All rights reserved.