Matt Heusser’s Blog
Testing at the Edge of Chaos
Interviewed on uTest
I had the pleasure of meeting Matt Johnston of uTest at October’s Software Test and Performance Conference. Matt is a Calvin College Graduate – the school where I teach Information Systems part-time. Go knights! Really neat announcements about software testing and Calvin to come in the next sixty days.
uTest is an interesting company with a unique business model. Companies put a modest pile of money on a table, uTest takes some of it, then organized a tester bug-hunt and disburses the money to it’s army of crowdsourced testers.
I’m not claiming that companies can use uTest to solve all their testing problem. The testers you get won’t be able to count on uTest as a day job, so they’ll test on nights and weekends, for the fun of it, for the professional growth, and, maybe, for a couple bucks. If the testing requires subject matter expertise; for example, if you are testing software designed to aid in managing venture-capital backed initial public stock offerings – well, it is unlikely uTest will find the deep business-process bugs.
But that’s ok; it means uTest can work as a test augmentor, providing yet another lever to help with testing. Throw $5K into a pot, hand it to uTest, and get a bunch of bug reports back. If you’ve ever tried to organize and run a beta program that got meaningful feedback from your users in less than two months, I’d say $5K and a weekend looks like a pretty good deal.
Anyway, Matt suggested we do an interview, which they have just posted. I hope you enjoy it.
/Performance/ Improvement, not “Process” Improvement
Would you be willing to go on a little experiment with me?
Pretend that you are an executive at an American Company in 1965. The story of Henry Ford’s Assembly Line, and the billions he made from it, have moved into the stuff of legend. “Everyone” knows that one way to make big money is to create a great product – one Americans wonder how they used to live without – that is disposable. Then, you break building the product into component tasks, get a cheap labor group of specialists to work on each task, and sell it to every single household, over and over again.
Enter Ray Kroc, businessman extrodinare. He notices that the McDonald’s Brothers have a better product – a burger – that people are willing to stand in lines for. Kroc buys the franchise, standardizes and defines every step in the entire operation, then takes it national. Then global. During his lifetime Kroc amassed a fortune of five hundred million dollars. Along the way, he acquires a major league baseball team.
What lesson do take from the McDonald’s story? Is it that the way to success it through standardization?
For many corporations, the lesson they took was exactly that.
I think they got it wrong.
You see, the McDonald’s Brothers had a great process to start with. They had a burger that was better than everyone else. So if you’ve got it all figured out allready – if you team has a “secret sauce” – it might make sense to do things in the same way. If you don’t; if the process is inefficient and slow and involves a lot of bottlenecks, then standardizing the process is going to prevent individual improvement.
But there’s more.
Part of Kroc’s goal was to produce a hamburger that was the same every time. His process was actually identical. In software development and testing, every project is different. We can try to talk in a language of standardization – “gathering requirements” or “requirements inspection” – but the actual requirements will be different every time.
Oh yes, there are rare cases where we really are doing very similar things; report generation, or just-slightly-different-each-time website development – but both of those are begging for some really strong 22-year-old codejockey to come along and write a code generator to make the problem disappear.
So in many cases in the corporate world, I’m suggesting we don’t need process improvement – at least, not the institutionalized, defined, audited kind. I suspect we need performance improvement. Let me give an example.
This summer, our family took a day off and went up to Michigan’s Adventure in Muskegon. The kids had a blast on the roller coasters and the waterpark, and I had one day to actually not think about technology or process. Until lunch, that is.
So it’s lunchtime, and I’m waiting in the line at the snack shack. A long line. And a long wait. They guy behind me starts to complain “You know, we come here every year. The kids love the park, but I spend the day in line. They need to do something about these waits for food. They really do. Maybe have one teen-ager work the cash register, another cook, and a third assemble the food. I don’t know. But they need some kind of process improvement to improve speed, that’s for sure.”
Man. Try as you might, you just can’t get away from it, can you?
So I start to talk to this gentleman, and I realize something about the teenagers behind the glass. They just aren’t moving very fast. I remember being a teenager myself, and the kind of jobs that paid the same minimum wage if I hustled or If sand-bagged.
A bigger assembly line with stations wouldn’t help the process. The food was pre-cooked, all the workers had to do was assemble it. What the workers had to was move faster.
There are lots of ways to accomplish that. One might be the McDonalds route; if the park was willing to invest the time and effort in hiring real process engineers. It’s easy to spread the cost of process engineers over 2,000 restaurants; over a half-dozen non-standard-sized snack shacks in a west Michigan Amusement Park, not so much.
Another would be simply to count the number of meals served in an hour, or the average wait time of the line. Then hand our raises and bonuses. You can do that with the register itself or with each manager simply using a stopwatch during lunch breaks. Or you could calculate the profitability of each shack and let the workers figure out the best way to make it more profitable. Oh, you might have to watch out to make sure the now-motivated workers aren’t serving undercooked food in order to make the numbers, but if you’re going to organize a group with managers, well, that’s part of the job.
Now, back in the world of technology, things are a little big harder. First of all, it might be safe to say that a dollar is a dollar or a minute wait is a minute wait, so those metrics are valid – but line of code are not creatd equal, and it is relatively easy to abuse them, or ‘test cases’ or most other engineering ‘metrics.’ Which makes management by output a whole lot harder then conformance to process.
So it’s harder. I don’t think that means we should abandon it.
In fact, quite the opposite. I think it means we need to work to understand the dynamics at play. We may not be able to turn the performance of a team into a metric, but I think we can manage for output. And management for performance is one of the things I am excited about right now.
I suspect that an outsider might see that kind of high-performance testing, snot and laugh that the work is the ‘very edge of chaos.’ Fancy that.
UPDATE: I’ve been reflecting on this, and I really have a strong emotional reaction to the standardized process thing. I dislike it. When I’ve worked with ‘process engineers’ who think in this command and control style, that want to separate the worker from the work … well, the reality is, they would not enjoy working in the very system they created. I expect they would hate it. Yes, they have ready-made excuses, like there are different kinds of people, some like to be told what to do, and fit well into the system, and others are more intelligent and independent and could not work in such a system, etc, and so on.
I don’t buy it. That is snobbery of the highest order; it’s nothing less than a new kind of class warfare, that replaces peasants with white-collar workers and nobility with executives.
It is also not treating people the way we would like to be treated. I wonder, as we Americans are about to embark on a two-day binge fest of Turkey and shopping, er, um, I mean, a two-day Holiday to thank our Creator for all the blessings he has bestowed upon us. I wonder if we should also stop to question our cultural assumptions about ‘process improvement’, and if they are an example of the Golden Rule … or not.
Update 2: At least one person read this as “Matt approves management by metrics.” Well, wait, that is a very complex subject. Please consider the post above in light of my other writing on metrics – this article comes to mind. How to do the performance improvement work in a knowledge-worker world, I suspect, deserves it’s own set of blog posts.
Keep it tuned here. More to come.
Skill Transfer and the Consultant’s Dilemma
I really appreciate all the comments about training last week. They really got me thinking about the state of our industry, skills transfer, and the consultant’s dilemma. Please allow me to explain.
Ostensibly, as a trainer, you have some ideas or experiences to convey. You want to have your students walk away, and, back at the office, actually /do/ test-driven-development, or performance testing, or some other technique. Or, at the very least, you want them to be better now at what they were doing before. So you want the skills you are teaching to actually transfer.
One term for this is “improving the client’s condition.” Now we could quibble about that; after all, only the client can improve things for themselves, and what does ‘improve’ mean anyway, but I think the basic vision of desiring your students do something different and better is a pretty good start. And, yes, there are pre-requisites; if the training isn’t interesting enough, or is too condescending, you’ll never even get a chance to help anyone out. They’ll be turn off before they start.
Which leads to what I believe is the key question: Does the training actually transfer?
How do you know? Well, the trainer could have a practical exercise at the end, but another way is by actually visiting the company six months later and ask how they do work now. The alternative, often called “drive by training”, involves handing out certificates and getting out of dodge quickly. Drive by training can be surprisingly lucrative, but it feels unsatisfactory to me. I hope you agree.
When the XP and Agile community read horror stories of “Fake Agile”, “ScummerFall”, and so on, and claim it is not true XP or Agile was not done ‘right’, we’re talking about a failure in skills transfer. Jerry Weinberg calls this the ’strawberry jam’ principle; that the further you spread the training, the thinner it gets.
So, while you can reach more people with a book than a course, and more with a magazine article than a book, at each level you run more and more risk that your students will get it wrong and not even know it, or give up without even trying. For example, does anyone remember RUP? James Bach mentions that the RUP development team never followed up to see if people could actually understand or ‘do’ the process in a podcast here.
So it we are going to talk about test training, our first real problem is this skills transfer. Our second, which I find just as challenging, is something I call the consultant’s dilemma.
That is to say, the typical student in a test training class has a set of assumptions about what testing is, how it’s done, and what it’s takes to do it well. They may have a set of values; for example, that standardization is good, that a repeatable process is good, that automation will save money, and so on. In many cases, these deep-seated beliefs defy life experience. When the team has four or five failures at test automation in a row, they will find reasons to find fault with the execution, not the idea.
So, as a trainer or consultant, you’ve got a problem. What the team (especially the management) wants to hear is how to make testing more stable, predictable, and repeatable. They want to hear how to automate the testing, to script-ify it, to make the individual humans dispensable, and so on.
It is very easy to sell training and get lots of high marks on the evaluation sheets by telling people exactly what they want to hear – how to optimize testing by creating metrics, templates, process descriptions, and so on. Even if you aren’t excited about the traditional methods of control, you can still help a team optimize a small piece within a given system.
The problem with telling people what they want to hear is that you aren’t actually helping them improve their condition. But providing evidence, challenging the premise of people’s deeply help convictions … that is an emotional hot button. Do it wrong, and it’s a great way to get not-so-great eval sheets and not invited back.
So any speaker, trainer, mentor, anybody who wants to influence change has to ask himself “If I kick in this direction, will I encourage change, or will I just kick over a bees nest? What is the right direction to push in?”
(I am speaking specifically of an invited trainer; inflicting help is something else entirely.)
The good news about the consultant’s dilemma is that you can use it as a heuristic to evaluate any speaker. Just ask yourself “If I had two years of experience in testing – or none at all – would the advice of this guy boil down to agreeing with my intuitive ideals, or is he actually introducing something new?”
To sum up: It is relatively easy to get high marks on evaluation sheets by telling people what they want to hear, and, quite honestly, hard to do so by challenging them. Oh, there are rhetorical tricks. You can start from agreement, and talk about what you agree on, then lead up to a contradiction or surprise. You can win rapport with the audience by -politely- pointing out the things we all do because of ideology, but they never seem to actually work.
I submit that if we want to advance as a community, and offer training with integrity, we’ll need to do better at the skills transfer problem and the Consultant’s dilemma. The reason I am excited about the Context-Driven Community is because that is where I see these discussions actually happening.
I have a few opinions on how to improve, and I can share those later. For the time being, what do you think? And what am I missing?
Update: One thing I’m missing is a technorati claim code, which is 2JMZ78N42HXA
You say you want a revolution …
Well, folks, I’ve got a lot of ideas intersecting right now that I would like to discuss, but first I have a bit of breaking news.
I’ve worked with several training companies in my day – some independents, some test/quality training companies, development training, and two colleges. Most of the time, the ‘curricula’ consists of ‘whatever we did last year that sold well, plus an idea or two to try out this year.’ (And changing courses at the college level? Good luck with that one.)
Some companies take a few more risks than others, but, for the most part, the inertia of old training materials make it hard for an organization to sense and respond to new events. In the short term, the company is incented to make small changes to existing materials and ends up, like Digital Equipment Corporation, optimizing the mini-computer and missing the personal computer revolution.
But every now and again you get a chance to start fresh.
In the past few weeks I have been approached by several consultants (and yes, one startup training company) for research on what training materials and courses they should offer around skills-based testing. That is to say, not just memorizing a list of words like “Oracle”, “Defect”, and “Fault”, but instead teaching courses with practical exercises designed to yes, help us actually test.
Sure, I can give my advice, but I am just one voice. My experiences as as training customer are limited, and so is my budget. Just about any individual is.
… but the readership of this blog, on the other hand, looks much more like the bell curve of software testers in the world, now doesn’t it?
So I am going to ask for your thoughts and time for that research. If we do it right, we’ve got a chance to materially impact the landscape of software test training in the world today.
The question is simple: Given all the experts on testing in the world, in what way could they organize, package, and sell training and consulting to make it appealing to your business or you personally? What are the barriers to the existing training options?
Example: Flying the team anywhere is expensive. Why aren’t there more local, small trainings in the big cities – New York, Chicago, D.C., Baltimore, L.A.? Or maybe the training should be web-delivered. If it were, how long and intense should it be? Do stand alone course modules work or do you want to be in a class-like environment? What should the core subjects bE?
I think the three-to-five day conference format, with tutorials on the first day or two, is a good thing. I also think that, as an industry, we are leaving behind opportunities to deliver specific training courses – for example, the quick attacks literature is testing gold, and could be an amazingly valuable one-hour course, possibly web delivered. That would certainly be a lot cheaper than a “junket in nantucket”, and offer a lot of value – but I’m not sure if employers would pay for it. And unless people hear that potential customers want it, I’m afraid they won’t develop it.
It’s not for me, at least not any time soon – I’m full-up as is. But when people ask me what courses they should develop, I will point them here. It’s a great time to answer the question “what should we teach?”
Thanks to the recession, I believe we have an opportunity to move the needle on how test training is delivered. Let’s not waste it.
What do you think?
November Software Test&Perf Magazine is out!
If you like reading this blog, you might enjoy subscribing to software test and peformance magazine, which will give you a half-dozen or more articles and columns a month, all in full color with nifty pictures. If you just want the PDF, you can even subscribe for free by registering for the site.
If you’d like to read our column it is on page 9. The subject is code coverage, an issue that we (especially developers) tend to throw around in a shallow way – hopefully this will put a little more meat on the bones.
If you’d like to have a specific issue – that some might seen trivial – covered in a deep way in STPEdia, drop me a note or leave a comment. Likewise, if you would rather have a single page covering a broad subject in a general way, to hand out to non-testers or new testers, let me know, we can do that too.
Heck, if you’d like to /write/ to ST&P, drop me a note. It might just be your turn.
Idealogy vs. The Software Process Naturalist
Several years ago, I worked with a company pursuing process improvement with the (then) brand new CMMI model.
To help us with this effort, we brought in a consultant from a consulting company with an “enterprise CMMI-5″ offshore development center. At the time, I was the chair of the QA Comittee for Software Engineering, and my role was to be the permanent party and ensure continuity when, six weeks from now, the consultant when home.
I could fill up several blog posts with stories about that effort; it was very enlightening for me personally, and helped define some of my thoughts about software process, American Business, and human nature. I would like to share one nugget from this part of my life:
Walking in the hallway after the meeting, the consultant turned and said something to me like this:
“Yes, Matt, this seems to be a good team. With a little work I am certain we can accomplish our goal of zero defect software.”
Oh, hey, wait. He never really did ask us our goal – he /told/ us our goal. I remember thinking at the time “What is that all about?”
“Zero Defect Software” rolls so quickly off the toungue. It sounds so easy. Like increased quality, reduced risk, and saving money, everyone should be for it, right?
Low defects, sure. Constant effort and improvement, absolutely. Zero defects, however, is really interesting. Where did that assertion come from, exactly?
I propose to you that the whole “zero defect software” thing is an ideology. That is to say, the speaker had an idea of how the world should be – then went and made up a theory of how the world could be like that.
When people talk about “theory” in software process, and say things like “I am not interested in theory”, I suspect they mean theory designed around ideology. If you dig far enough, you can find ideology in the CMM, in UML, In “Software Architecture”, In COCOMO2, function points, and in many other fads that are slowly fading.
We can do better.
What if, instead of making up theories about how software projects should be run, we instead studied software projects to try to understand what actually works? What if, instead of trying to generalize, we studied what specifically happened in specific situations, so that next time we can say “hey, this reminds me of the time …”
Do it often enough, and we start to slowly build a behavioral model about what is actually happening on the projects we are working on. You may not be able to articulate the model precisely, but when the PM says it’ll be done on time, and you snort and reply “there’s no way this is done before Christmas”, or “Yes, it’ll be done. Three weeks late. And Buggy” and you are right – tell you that your mental model is effective.
Now based on that model, slowly, we can observe patterns of what actually works. Out of my experience in commercial software in North America, I have come to believe that what the customer wants will probably change – so today’s working software is tomorrow’s defect. That feedback is a critical part of the process, and that it’s better to deliver a 20% solution today, 40% tomorrow, and so on that 100% at the end of the week.
I also believe in engaging the worker in the work – that the best ‘processes’ are defined by the workers themselves in order to do the job better, instead of being imposed with a goal of ‘limiting variation.’ Moreover, I believe in the power of choice in the workplace – and that standardization is rarely the way to get to that.
And then there’s the value of a project-based team working on delivering the software, instead of creating single function ‘teams’ where each member competes and all work on different software projects.
Likewise, because we communicate in symbols that can have subtlety different meanings for different people, there is a sort of information loss that happens in communications. In person, we can fight for it, by looking at a person’s body language or asking them to repeat the idea back to us. The problem with the conversation is that the information is often lost, but we can reinforce it through daily standup meetings, pair programming, wikis, and other tools. Written documentation, on the other hand, is even more lossy – the original author has no idea if his writing came through, and no opportunity for feedback.
So how much to write, and how much to say, is a question of how much to invest – a trade off.
All of these are little things I have noticed by observing software teams in the wild. They may not fit a particular ideology well, but they are important, because by noticing them we can design a software system to have less loss and more self-correction. Likewise, we can walk into a development shop, listen, and provide some advice that might actually be helpful.
In a nutshell: Let’s get experience first, and build our theory from there. Another term for this is constructionism, or, as I first heard from my friend James Bach, to be a “Software Process Naturalist.”
That means instead of saying “You’re doin’ it wrong!” We say “Well, you could try that. And if you do that, I would expect you get these results. Now, are those the results you want?”
That’s a kind of software theory I can, and do, get excited about. I’ve been doing it for years, and am just beginning to get to the point where I might consider formalizing it.
… but what do you think?
We have a winner!
In my last blog post, I offered a simple challenge: Find a significant defect in my chapter, and I will mail you a copy of the new book, Beautiful Testing.
I am pleased to announce Dawn Cannan as the winner of the contest, with Marisa Seal as an honorable mention.
… and there is a problem. Dawn already owns a copy of the book.
So I offered to purchase her a one-year membership in the Association for Software Testing – but the AST website is down after it was hacked.
So now I need to come up with a prize, at roughly $50 USD value. Should it be a one-year membership to STPCollaborative, with full search and rights for the entire history of the magazine? Should I try to get a nice STP long-sleeve button-down shirt? (No promises; those go to full-time employees. I don’t even have one – but I could ask)
Or something different entirely, say an Amazon or Best Buy gift-card?
That dear reader, is where you come in. Could you help me find the right prize for Dawn?
Now I want to keep in mind that everyone that entered the contest and found a defect is, in a way, a kind of winner – and I would like to reward you as well. First off, when the Beautiful Testing book website is up, I’ll list your name in an “errata sheet.”
Second, if you found defects in my writing and are inclined to do more peer review, you can join my yahoo group where we discuss software writing projects still under development – prior to publication. If you’re not interested, that’s fine too – but I thought it was worth mentioning. For more information, you can email me at Matt.Heusser@gmail.com or follow @mheusser on twitter.
Thank you all for participating; if you find more bugs, you can leave them on the prior post.
… and now for the real question: What’s an appropriate first prize for an excellent tester and book reviewer? IF you could have any prize of that value, what would it be?
27 authors, 23 chapters, 10 months in development and …
… It’s here!
I’m sitting at my desk, looking at my copy of “Beautiful Testing.” I picked it up yesterday from my local Barnes and Nobles – on the shelf! I am so excited. (No, don’t ask me why I was able to get it from Barnes and Nobles before my author’s copy arrived in the mail. Yes, it is a touchy subject.)
The book is a collection of twenty-three essays from people involved with testing – testers, developers, even a few management types. The lead organizer, Adam Goucher, tried very hard to get multiple perspectives, so we have everything from Lisa Crispin (co-author of Agile Testing), to Alan Page of Microsoft, to John Cook who work in academia, plus myself, Karen Johnson, and Chris McMahon – and quite a few people in between.
“But Matt”, you say “It’s Fifty Bucks. FIFTY BUCKS. C’mon, man, you’ve got to help me out.”
Well, I’ve got good news on two counts. First of all, all of the author’s royalties from the book go to a charity called “Nothing But Nets“, so you can feel good about it when you buy it.
“But Matt”, you say “How can I know the book will be any good?” Well, okay, fair enough. The good news is, I have permission to redistribute my chapter – I’ll even offer it, right here, on my blog as a PDF, for free. (Click to download).
Don’t say I never gave you nothin’.
What, you want more? Seriously? Ok, one more thing: When I read my chapter this morning, I discovered a significant and substantial typo. Be the first person to find that typo, or another typo that I agree is at least that significant, and I will order a copy of the book and have it mailed to you.
To submit a bug, just leave a comment. (I’d also like to know what you think about the chapter, but that’s just me …)
Why Agile? Why Now?
I’ve noticed something really odd in the past three months – I’ve started to write articles about Agile Software Testing.
Oh, this is no big surprise, I mean, I work at a shop that releases working software to production every two weeks, uses pair-programming, test-driven development, plans releases using stories and story-points. Typical Agile stuff.
While I have always been interested in lightweight methods, fast feedback, and personal excellence, a quick check of my old published articles finds all of three with “Agile” in the title – one was for a magazine issue with an Agile theme, a second was an interview, and the third, “Peril and Pitfalls of Agile Adoption” was not entirely complementary to the subject.
At the same time, there has been an explosion of Agile Books, Agile Consultants, Conferences and Advice. This morning on twitter, my writing partner, Chris McMahon claimed the Agile Advice ‘market’ was ’saturated.’
It’s pretty easy to argue that if you are a thinker looking to not become part of the herd – that Agile in 2009 is probably not the place to be.
And yet, all of a sudden, here I am talking about Agile Testing. In the two months I’ve published:
Using Automation to speed up Agile Testing
Test-Driven Development Face Off: Part I
Test-Driven Development Face Off: Part II
And I’d like to keep going. Why the sudden energy? Why am I suddenly interested in the ‘Brand’ Called Agile, when I typically suspicious of labels in general?
Here’s what I think is going on. The Agile Manifesto is getting on ten years old. Since the manifesto was developed, we’ve had at least two generations of dogmatic thinking – the XP years, then the Scrum years. We’ve had a fair amount of chest thumping and experts talking about the “right” way to do it and the “wrong way.” We’ve seen practices (someone) doesn’t like labelled #notagile, followed by someone else pointing out that it’s not the practices, it’s the principles, followed by … you get it.
And, quietly, over in the corner, some people were actually shipping working software to customers, and continually getting better and better and it – and – in some cases – developing the skills to talk about it.
After a decade of Agile development, we’ve got anecdotes, we’ve got stories, we’ve got experience. And I can start to reply to the chest-pounding and dogma by saying “really? Let me tell you about my experience. What was yours?”
In other words, I believe the Agile movement has a chance to move beyond dogma and into actually talking about systems thinking and tradeoffs.
We have a chance to have an entirely different kind of discussion around Agile Software Development and, about that, I am excited.
… but what do you think? Has the ‘Agile Software’ movement hit a brick wall or just gotten started? Do we have opportunities to move it forward?
A Quantitatively Managed Process
There’s a value system out there that says that in order to prove any argument, you need data – and not just any data, but hard numbers. (My father in law, David Ellinghausen, a quality engineer at Ford Motor Company for twenty years, once told me “Without data, your just another guy with an opinion.”)
But let me tell you a story …
I work at a Software As A Service (SaaS) company. We have a website; customers pay us money for a login to the website, then pay for access on a monthly basis, typically on an annual contract. If we provide good service, people renew, and the revenue graph is a big, up-sloping curve. Why, to make money, we don’t have to do anything but keep our customers. Yes – it turns out, as the quality of web apps continues to improve, that’s a bit of an understatement, but I hope you see what I mean.
Now, imagine it’s the beginning of the first quarter of a the new year. We engaged a outside form to perform some research for us – to figure out our customers budgets, their social media strategy, to determine our budget and sales quotas. Picture these two different scenarios:
Scenario 1: The account rep bursts in the room, his face flushed, his tie loosened, with some papers in his left hand. He gulps, looks at the floor, slowly looks up, turns to the CEO and says “We just finished running the numbers. 20% of our customers are not planning to renew next year.”
Scenario 2: The account rep walks into the room, smiling. He shakes the hand of the CEO, gives a high-five to the VP of ops and VP of sales, puts his briefcase on the desk, unbuckles it, and pulls out a glossly, one-page overview, complete with pie chart. “Business is up.” he says “80% of our are customers are planning to renew this year.”
How would you expect the executives to behave in those scenarios? Very differently, right?
… wait a minute …
Those two account executives just said the exact same thing.
As well all know (my friend Michael Bolton pointed it out again last week at STPCon), even when we have them, we do not make decisions based on numbers. We make them based on how we feel about the numbers.
Numbers (quantities) don’t manage processes – people do. Oh yes, there are rare exceptions that are interesting optimization problems. For example, how much inventory to keep on hand for the Christmas rush – too much and you’ll waste money, too little and the shelves will sit empty. But ask a computer to recognize that a shopping mall was just put in accross the street, thus foot traffic will improve … it won’t do it.
For that, you need a human as the master, with the number as the servant, as it should be.
