Michael Hunter
Hello!
Welcome to Uncommon Leadership.
I’m Michael Hunter with Uncommon Teams.
Today, I’m talking with Michael Bolton.
Michael is a consulting software tester and testing teacher who helps people to solve testing problems they didn’t realize they could solve. Michael has over thirty years of experience testing, developing, managing, and writing about software, and has traveled to six continents to help people learn about testing.
Welcome, Michael!
Michael Bolton
Thank you, Michael. Two Michaels.
MH
And so it’s what, North America that you haven’t been to yet?
MB
No, that’d be the big white one down at the bottom. Which is slowly being exposed by climate conditions. It’s, I don’t have a whole lot of ambition to go there, but it’s on the list.
Maybe they need training in Rapid Software Techniques at one of the outposts at the South Pole. That’d be cool.
MH
If you held software classes outside, it would definitely be rapid, especially in their winter.
MB
Yeah, we’d want to get it over with fairly quickly.
MH
That is probably a workshop idea.
MB
There you are.
MH
In your journey to seeing people as people and learning to leverage their unique gifts to best accomplish your goals, when did you first recognize this might be a valuable approach?
MB
That is an interesting question. This is not my first career. I wasn’t a computer science student or I wasn’t a software engineering student or anything like that. As many people in the testing field can describe, often end up here by a set of, anywhere for that matter, but we often end up where we are by a set of coincidences and accidents and so on.
My first career was as a kids theater stage manager. And kids theater, to be clear about it, the actors were adults, the shows were for kids, we toured from school to school.
And that was my first foray, really, into management of any kind. My job was to make sure that the show went on and remained consistent with the director’s ideas about what it should be. To get the set up, cause it was quite elaborate, we would go to two schools a day. We had a lighting and sound rig that we would pop up within about forty-five minutes before the show, and then we do the show, and then we pack it all up, put it back in the van, and drive it away.
In that role, one of the things that I came to appreciate was that performers are wonderful, and talented, and annoying, and vulnerable, and helpful, and needed help, but each one contributed to the show in different ways. And theater works like that. A lot of diversified talents collaborating and cooperating.
Some of the actors were really high-strung. Some of them were really easygoing and relaxed. What became important, because we were five people, four or five people, depending on the show, in a van all of a sudden basically married to each other, we’re this close and we never, nobody had ever asked to go on a date with each other, I came to recognize was how each person had a different kind of contribution to the company, to the show, to each other.
If you’re putting me on the spot and asking me that question, when did I first really engage with that, that would be about the time.
That’s in my early twenties. So what is interesting is you wouldn’t believe how dealing with very talented, and to some degree high-strung, actors can prepare you for being a program manager in a software development company, which is someplace I went after that. That’s the first place that it really confronted me that each person has a value to contribute and each person has stuff that they need help with. And I was there to help them with that among other things.
MH
How did you help them understand who they are back then, that you are still doing today, helping the people you work with today understand who they are and how they could work best and how to bring that into the work that they do?
MB
I think that goes really well with one of the fundamental premises of Rapid Software Testing, which is the methodology, the approach, that James Bach created and that I cocreate with him these days.
And that is that the tester himself or herself is at the center of the testing work. Software development teams, testing teams, get their strength from diverse talents, diversified skill sets, diversified temperaments, diversified preferences, working together in concert with each other.
Fundamentally, one of the things that’s important about testing is that it brings distance from the builder’s perspective and brings a new perspective that the builders and the designers don’t necessarily have. And one thing for sure they don’t have is a laser focus on trouble.
That’s what we’re trying to help testers emphasize, that everybody else on the project is focused on envisioning success. They’re trying to build a product. To do that successfully, to some degree, depends on suppressing the idea of the possibility of failure.
It’s very nicely put, actually, in a documentary called General Magic from 2018, highly recommended viewing, in which they described that problem, that the people who were building the project were not particularly focused on, on things that could contribute to it collapsing, and of course, by about 1995 or so, the project, which had started in 1989, essentially a project to build what we now think of as a smartphone, that project collapsed largely because they weren’t really dealing with the possibility of trouble, the possibility of failures.
Now, on a test team, there are numbers of ways in which testers can follow their lights and follow their preferences and be especially helpful. Some testers are very social. Some testers are very oriented towards administration and organization. Some testers are very technical and are interested in the nuts and bolts of the machinery. Some testers are very analytical at creating models of complex kinds of realities. Some testers are very spontaneous. Others are more deliberate. That diversity really adds, to the task of finding bugs, because there’s another place in which diversity can be found really easily, and that is bugs. Bugs have certain patterns associated with them, certainly, but every new bug is like another individual. It’s like a distinct person who shows up in certain kinds of contexts and doesn’t show up in other kinds of contexts, each one of them a reflection of errors in people’s models of the world and people’s thinking and people’s typing. Each different kind of bug has its own personality.
Now there’s a fellow named Ross Ashby, one of the leaders in the general systems movement, who pointed out that only variety can overcome variety. He actually coined this thing called the Law of Requisite Variety: if you want to understand or control a system, you need more states available to you than the system itself has.
And that works in bug finding as well. If you’re going to find lots of different varieties of bugs, you need lots of different varieties of people who are capable of putting the system into a large variety of states and making a large variety of observations. In that sense, every person has enormous potential to bring new perspectives and new ideas and new approaches, and therefore the potential to discover new bugs, to any team in which they’re a participant.
MH
The work that you do, the way that you approach testing and software in general, emphasizes more than some other methodologies, bringing those unique perspectives. How do you help companies who may not have yet discovered the benefits of diversity in perspectives and ideas to experience and realize?
MB
I wish I knew how to do that better.
One way of doing it, and we do this in the classes a lot, is to put something in front of people that looks like an easy problem. That looks like a straightforward, ordinary, a problem in logic or a straightforward ordinary problem in deep processing of some kind.
And then our exercises, almost all of them, I’m struggling to think of one that isn’t like this, but our exercises are mostly founded on real bugs that we’ve encountered in the wild or real testing situations that we’ve encountered that are likely to be different from the way people have experienced things. Because, as I said, every new bug and every new product is unique in some sense.
So that’s one way we do it. We give them apparently simple exercises that turn out to have a lot of depth associated with them.
But another thing that we do in class is quite a bit is we get people to look at each other’s work. We take the contents of the exercises and post them in public places one way or another. We use a chat system called Mattermost, it’s a Slack-like kind of system, whereby people can share their findings and their artifacts and their their ideas about how to test something. So what we can show people is that even within an organization that is stodgy or hidebound in some way there’s a big diversity of ideas already there.
And then our job is to help people who may be a little bit stuck to see that there’s even more ideas from outside elsewhere in the world.
I credit my friend Rob Sabourin for speaking of this. He talks about something which is part of learning theory, education theory, called critical incidents. The basis of the idea is that if you put someone in a position where all of a sudden you shake them up a little bit or show them something that doesn’t fit with their current worldview, or if you provide them with a puzzle that suddenly has a an approach to solving that they’ve not seen before, they get trapped by their original conception of the thing. So we set a lot of traps in the class for people.
The idea behind that is not to make them look or feel stupid, but to put them in a place where they’re going to experience an epiphany, a critical incident, in a place that is not dangerous, not risky. Nobody cares if you screw up an exercise in our class. Nobody judges you for it. We don’t mark the classes. So you’re allowed to make mistakes in a trouble-free environment.
But here’s the thing: a lot of the time people create traps for themselves that we never put them in.
And a lot of times they discover solutions to the traps that we never thought of.
We’re learning from teaching the class a lot about how people go about the business of problem solving and problem identification. Where we got a lot of that, because you’ve not only taken the class, but you too are a student of Jerry Weinberg and the experiential learning paradigm that he followed for much of his training work, and we take our hats off to Jerry for, among other people, Cem Kaner was another course, of that kind of a discovery process.
MH
It’s always fascinating to me that even in these environments, like your Rapid Software Testing course, Jerry’s various experiential workshops, that are explicitly, everyone there knows this is a safe place to not succeed, the point here isn’t to get the answer the fastest or the best or the most brilliantly. The point is to, as you said, experience new perspectives, stumble over parts of how you approach problems or parts of who you are that you may not have recognized are there, or are a different scale or scope than you realized.
And yet, how many people show up in your class and you can tell are afraid to let the other students or certain of the other students for whatever reason to see that they’re failing or that they don’t have the answer or are trying to always be the first one with the answer or show that they’re the smartest or all of the dysfunctions that they have in all the situations where there is a much higher risk of failure.
MB
That’d be me.
I’m one of those people who, I have a real struggle with trying to, because I was socialized to do this.
I was a really bright kid, reportedly, allegedly, and I was short, and I was precocious. So, I got a lot of happy feedback from people, “Oh, isn’t he clever?” And so I started to get this belief that it’s really important to be clever. I got fed a lot of attention as a consequence of that. So, that has become for me, a kind of lifelong addiction that I struggle with all the time.
But then there was a wonderful line from the movie Broadcast News. I don’t know if you remember that or if anybody else does. But there’s this moment where a very capable news producer is speaking to her boss, and she goes up to him and says, “You’re going about this the wrong way. You’ve got the wrong person in this job. You need to get this other person in to do this job.” I think it was to cover a particular story. Said ” You need to give him a chance. And this other guy that you got in mind is not right for this job.”
And the boss says to her, “I’m just absolutely wrong and you’re just absolutely right. It must be wonderful,” he says, “to be the one person in the room who’s right all the time.”
And she says, “No, it’s awful.”
There’s a struggle, because of course, once you feel like you’re the smartest person in the room, or if you let yourself believe that, you’re gonna miss a lot. And I do sometimes.
But on the other hand, I look at my experience playing Irish traditional music, which I play on the mandolin and on the banjo, and I realized at one point, I love being the worst player in the room, because I can learn so much from everybody else and it sounds way better than if I’m the best player in the room, quite naturally, especially when I’m the only player in the room, then it doesn’t sound as wonderful as I would hope. So there’s always that kind of tension there.
And I think Jerry was very cognizant of that in his life and work because so often he would have been the smartest person in the room. And I think he grew to recognize the risk of a, feeling that way, and b, believing it to be true. And yet, whenever I was in a room with him, it was often manifest that he was an incredibly smart person. But like anybody else, he wasn’t right all the time and none of us can be.
So it’s a, it, I think that’s a natural human kind of tendency for lots of people.
There’s another one, which I think is really damaging though. And that is the persistent belief that you are the dumbest person in the room or that you’re not smart.
One of the things that we try to do in our classes a lot is we try to honor everybody who goes through and help them to recognize, “That was clever,” when they do something clever.
And if we’re paying attention, everybody’s doing something clever from time to time.
And then, just like me, everybody’s doing something stupid from time to time.
The key is to honor that, to observe and to notice when people are inventive, creative, productive, clever things, and to recognize that’s available to everybody, that everybody has the capacity to do that on some level. And we get ahead by doing it helping each other along with that.
MH
How do you notice all these moments where someone’s, a student is, doing something right, so that you can highlight that back to them in the midst of all the crazy that is a real life class. You’re trying to keep on track and fit into the time schedule and all the other things cause it to be not just an easy-going conversation between you and a few other people.
MB
That’s hard. And that’s one of the skills that I have tried to work on for years with only a modicum of success.
The key to it is to go in with that premise. And to remind myself to look for it and to watch it and to notice.
And once again, sometimes I fail in doing that. And sometimes I make systematic errors in evaluating people’s temperaments because we are all imperfect observers. If we were perfect observers, we wouldn’t need testers. I, on several occasions, I’ve wondered about somebody enjoying the class or not. When I ask them to speak, sometimes they’re reluctant to do that, or sometimes I just fail to notice that they, haven’t spoken very much.
So there’s a tension between giving the introverts space to be introverted and quiet people space to be quiet. Because I can’t presume that they’re going to be a noisy person like me.
So sometimes I get fooled by that. I think maybe they’re not enjoying the class or they’re not engaged with it. And I make the mistake of believing they’re not having a good time.
When if I were able to focus a little bit more expertly, I would realize that they were having a wonderful time, as sometimes people have pointed out. I get to find out later in, in comments and so on and feedback after the class.
So to do that, to notice when people are doing something which is praiseworthy, it’s a skill. And it’s got to be practiced, it’s got to be exercised, and it’s got to be deliberate sometimes.
And I, once again, I have a bias towards talkative people, cause I’m that way myself. I’m really anything but an introvert most of the time.
But that’s part of the journey of being a teacher and being a consultant for that matter, too.
MH
We’re talking a lot about your experiences through class, because you teach a lot about class, which for me, everything that you said, there’s clear parallels between you as a teacher and the students in the class and us as leaders and the people that we are leading and the people that we are being led by. What is the biggest, it’s not a parallel between sort of those two different worlds you’ve experienced? I’m curious if, where this metaphor of everything that I, as a student or I, as a teacher in a class or a seminar, workshop, experience and struggle with, mapping to what I, as a leader, I, as a person following experience, struggle with, where that falls down.
MB
Everything is like everything else. In every way.
And everything is unlike everything else in every way as well.
That’s it.
I love that you use the word metaphor because that’s really what it is.
A metaphor is something that’s simultaneously true in some sense and a complete lie in another sense.
My love is a red rose. What, she’s got petals? She’s actually red, or she’s green in certain parts? She’s got thorns?
But it’s the images and the associations that we make in our minds that are the power of metaphor.
Now, of course, that sounds weird when we’re talking about the very sort of rationalistic world of software development.
But really, metaphor is, one of my books back here, not sure, I think I’ve got it in paper form, but it’s a book by Douglas Hostadter. And I remember the theme of the subtitle. I’m drawing on the title of the book, but it’s analogy as the fuel and fire of thought.
Obviously, in a classroom, the stakes are lower. In a consulting role, which I really love to be in, the conversation that I’m having with a person or a group isn’t the work. That’s not, we’re not writing any code in those moments, but we’re talking about it.
And at the same time, this is another thing that came entirely from Jerry, is when you set up an exercise, obviously, in a classroom, it’s not like the actual circumstances of working, if you look at it on a certain level, but what is really interesting is people reproduce their culture all the time. When I go into a meeting with a group of people, for example, at a company the dynamics in that meeting are super consistent with the dynamics of the meetings that they have when I’m not there.
This still is burned into my brain: give them an exercise and they will replicate their culture. Which is really interesting.
And yet at the same time, exercises in class are not like that. Not like the real work on some level.
So there’s always a, again, another kind of tension there between those two things.
Does that answer your question? I want to check and make sure.
MH
It does. And this is, if there’s one thing for us as leaders to remember, to help us perceive what’s really going on, I might frame it as what you said, that everything we perceive is exactly true and it’s all exactly false.
And as long as you remember that both of those are true and false themselves.
MB
You’re helping me actually to phrase it better.
There is a book whose title I do remember back there called Discussion of the Method by a fellow named Billy Vaughn Koen. I believe he’d pronounce it that way. K O E N. In which he points out that the universal human problem solving method is engineering.
You’d expect that from an engineer, which he was.
But by engineering, he had a very broad notion. His notion of engineering was essentially anything that people do to make change happen. An example that he gives in the book is, Henry the Eighth engineered his divorce from Catherine of Aragon.
So he’s, his book Discussion of the Method is about the engineering method. What’s that? His reply is that the engineering method is the application of heuristics. To make the best change in an uncertain situation, given the constraints, was a heuristic.
In the sort of succinct definition that James and I have arrived at is that a heuristic is a fallible way of solving a problem. Something that can work, that might fail.
But Koen makes the point in his book, all is heuristic. Everything is heuristic.
What’s a counter to heuristic? Algorithm. An algorithm does guarantee a correct answer. And does guarantee that it will conclude. We can have algorithms for all kinds of stuff.
But, algorithms work specifically in formal systems. As soon as we leave that formal system and enter the glorious, messy, complex, interactive world of human relations, all of a sudden, the algorithm itself turns into heuristic.
Because, for example, there’s an example we use in the class that long division is a perfect way to decide for a two hundred dollar bill at a restaurant how much each of the four people should pay. Perfect solution. But it doesn’t solve the social problem of the fact that one person around the table had the main only, and I had an appetizer and two glasses of wine and the main course, which is the most expensive one on the menu, by the way, and the dessert. The algorithm solves a mathematical problem, the formal problem, but it doesn’t solve the social problem of what’s fair, what’s good.
When we see that tension between everything, everything is always true and everything’s always false, what we’re really talking about is that our approach to encountering the world, and being in the world, has to be a heuristic approach. I don’t know of any problem solving method outside of a formal system that is infallible, that’s not subject to variation, that’s not subject to change, that’s not subject to a differentiation when we force our attention on it.
And the force or attention doesn’t have to come from us either.
Nature itself shows that everything is heuristic.
Nothing in nature is eternal.
And that’s the nature of all kinds of systems.
Including the ones that we choose to construct.
MH
I like this. If I as a leader can remember all I have to work with are heuristics, then I know that there is no guaranteed way for me to succeed. Which removes so much expectation from myself and so much fear of, “What if I fail?” Of course, I’m going to fail in some way. And of course, I’m going to succeed in some way.
MB
Yeah. On some level. And Jerry was great about that. It, so many of his aphorisms, my goodness I sometimes do this as a joke, but every time I mention the name Jerry Weinberg, a little, another bell goes off again. And if I paid myself for how many times I evoke him or mentioned his name, I’d be a wealthy man if I could get the money for it from somewhere else.
Jerry was fond of pointing out that if you screw up gloriously, magnificently, horribly, it’s never a total loss if you learn something.
And that’s the other dimension of the word heuristic, by the way. It’s very closely related to the word, the roots are the same, for eureka, I’ve discovered it, heuristicos, I believe is the root.
And that means in Greek, so far as I know, a serving discovery.
And I don’t, I’d prefer not to screw up, I prefer not to fail.
But if I try to deny that it’s going to happen there’s this piece of machinery called the reality steamroller that’s going to come along and literally flatten me out.
Not literally.
Metaphorically.
I used literally just to invoke how clearly the image of being flattened out by a steamroller would be.
But isn’t that wonderful? Words are heuristics, images are heuristics, models are heuristics, and that’s it’s like the drum and bass line for our work in our classes.
And our consulting work as well. Everything is a heuristic.
And that I’m absolutely with you on that, by the way, that once you realize is failure is not an option, no, it’s not an option. It’s inevitable.
On some level, it’s some to some degree, that’s actually freeing in a way. Because we can’t, I don’t think it’s reasonable for us to promise perfection.
It’s always reasonable, it seems to me, for us to aspire to a good-faith effort.
But even that is not always reasonable. We try to purge that from our discourse, “always” and “never” and words like that.
MH
Now that we have solved every leadership problem ever, what else should I ask?
MB
What a relief!
Oh gee, I don’t know. “Should” is an interesting word there too. There’s a heuristic that I like to apply sometimes, and that is to try to substitute should for could. And at that point we run into another problem is that there’s a blizzard of possibilities there.
MH
Let me rephrase it. What else would you like me to ask you?
MB
Oh, again, a blizzard of possibilities there, too. You could ask me a little bit about the book that James and I are writing, maybe?
MH
Sure. Tell me all about the book that you and James Bach are writing.
MB
It is called Taking Testing Seriously. We’re anticipating it’ll be out by around October or so. That’s when Amazon believes it’ll be able to ship it to you.
We are taking the perspective that we’re going to write a bunch of stuff as one part of the book, and we’re going to elicit contributions from members of our community for the other parts of the book.
And each of the, you can call them essays, each of those will help to illuminate ways in which our approach, Rapid Software Testing, has found, or has helped people to deal with certain kinds of things or think or talk about testing in sharper and more serious kinds of ways.
So that’s one thing you could ask about, but, oh, my goodness, I’ve answered it already. There we are. You’re going to have to come up with something else.
MH
That’s great.
One thing I learned from you is that techniques, approaches, successes, failures, from other disciplines, other complete parts of society often have application, maybe I might venture to say always have some relevance to software and leadership as well. So, I’m excited to read the book when it comes out and discover how these learnings from applying Rapid Software Testing apply to other parts of software, other parts of leadership, other parts of life.
MB
Yeah, me too. The essays are coming in. We haven’t got all of them. And of course, as authors of the book, part of our job is to edit those essays and to, of course, along with the professional book editors who are doing that stuff as well, but to try to help shine light on these different and quite diversified approaches that people apply and that people alter.
One of the things that’s interesting and paradoxical to some degree about our methodology is that we’ve got a bias.
Our bias is towards doing the fastest, least expensive testing that still completely fulfills the mission.
And the mission of testing in, that’s most prominent for us, is the mission of finding problems that matter before it’s too late, before we inflict products that have problems on our otherwise unsuspecting customers.
That bias, of course, has to confront the fact that sometimes, very fast and very inexpensive testing is sometimes not possible and not desirable when problems are deep, hidden, rare, subtle, intermittent, emergent.
And so a big part of what we try to do is to try to help people notice when risk is ramping up and when the risk of subtle problems that aren’t obvious right there on the surface can be a big deal.
At the same time, we want to identify that all that stuff that people are talking about as being super important in testing these days, the vast suites of automated checks, they have incredible usefulness for what we sometimes controversially refer to as shallow testing.
When we talk about it is not a moral judgment and it’s not an insult.
But what it is, if you like, it’s a framing and potentially a warning because of two things. One, we don’t want shallow testing to become too expensive, and we don’t want shallow testing to be the be-all and end-all insufficiently deep.
So, we got those two things pulling on each other at the same time as well.
The shallowness of shallow testing is every bit as much a feature as it is a bug.
Shallow testing allows developers to make really rapid forward progress because it’s nondisruptive. It doesn’t slow the developers down very much to run a bunch of fairly insignificant, fairly trivial checks to help maximize the chance of finding every easy bug.
Not maximize the chance of finding every easy bug but at least provide some chance of finding every easy bug.
Deep testing, by contrast, is designed to maximize the chance of finding every elusive bug that matters.
So if you wanted to sum up Rapid Software Testing in a way, you could say our goal is to make shallow testing deeper and deep testing cheaper. You can do that.
But there’s another, there’s a paradox at work there too.
When we teach the class, one of the things that we try to emphasize is that our students aren’t going to leave with the James Bach version of Rapid Software Testing or the Michael Bolton version of Rapid Software Testing, they’re going to leave with their own notion of it, their own model of it, because we believe fundamentally that every tester must invent testing for him or herself to some degree, to a significant degree, because once again, we place the tester at the center of the testing.
So there’s a paradox there.
We have very strong and experience-based opinions on what’s going to help and what’s going to work in testing.
And then we’re confronted all the time with circumstances and contexts and exceptions where our fabulous idea ain’t gonna work or it will be too expensive or it will be too inexpensive.
So that’s the value, it seems to me, of including these other perspectives in the book because we’ve learned our most significant lessons on many occasions from insights from other testers.
There’s a sort of paradox right at the heart of the methodology, which is testing is, we believe, should be this way, and we believe that you shouldn’t believe us.
And again, all is a heuristic.
MH
Absolutely.
If people would like to get in touch with you to talk about applying heuristics, the way we’ve talked about today, to solving their testing and perhaps other software leadership, life, related problems, what’s the best way for them, what heuristics should they apply for getting in contact with you?
MB
There you go.
One heuristic is use a search engine and just look for Michael Bolton, except that can fail because you might end up getting that singer guy. Add the word testing and you’ll find a variety of ways in which I can be found.
Since Twitter started spelling itself with an X, which I, somebody’s missed an opportunity. That should be pronounced “shitter,” don’t you think? But anyway, since that’s deteriorated, I’m on there less and less these days, but I’m there occasionally.
Probably the best way though, is to go through a straightforward email, michael at developsense.com. And you can find me through my website. I’m on LinkedIn. My, on my website, you can find contact information and you can phone me if you like.
I love speaking with people and helping people out. I offer that as a form of engagement. Anything will do. Email, LinkedIn, Twitter sometimes, the phone, there’s contact information on my site. You could write me a letter if you wanted to. You can, anything will do.
MH
That sounds great. Thank you. And I’ll have all those links in the show notes.
MB
Splendid.
MH
What would you like to leave our audience with today?
MB
We are entering a very weird and I would believe dangerous time.
We live in a world as a, I’m not sure who coined the word, I think it was Meredith Broussard, and I think it’s a brilliant word: techno chauvinism. Not just chauvinism from the, on the basis of gender, but also chauvinism on the basis of choosing things with profound biases.
These days, solutions to problems don’t count in certain circles unless they’re technical or, technically- or machine-focused kinds of approaches to solving problems.
And right now in the age of so-called AI, artificial intelligence, or as James is fond of referring to it, algorithmic irresponsibility, we’re living in a world where people are tremendously excited by magic wands that are being handed to them in the form of large language models and machine learning algorithms more generally.
These things are very powerful and they’re very interesting.
As we mediate our words, our observations, our engagement with each other, we amplify and extend and accelerate and intensify and enhance and enable all the bad things just as easily as all the good things.
We amplify our virtue, but we also amplify our capacity for failure.
People talk about how wonderful it is, for example, to have machinery check the output from functions in a product.
That indeed is a fairly wonderful thing.
But we got to be careful.
Because a lot of the time, when people have a narrow kind of procedural view of what it means to test something, it ends up in testing that’s not terribly helpful, not really great at finding problems that we would be able to identify if we bothered to get experience with the product, actual experience in the ways that users do, but also just experience with the product ourselves as people who are contributing to its development.
So, one of the things that happens these days quite a bit is that machinery separates us from the product.
It can allow us to get really close to the product, but it can also separate us from our experience of the product.
We got to keep that in mind, it seems to me.
What is in play at the moment in the world, so it seems, is this endless acceleration of desire to get products to market, to make great big money, to create a little company and expand it and serve it, solve a certain kind of problem, and then just sell it for vastly more money.
These things have their dangers.
And the biggest danger at the moment, it seems to me, is to get into this weird belief that when it comes to code and working with code, when it comes to products and developing products, that machines are just basically fundamentally better than people.
And they’re not.
They’re extensions of ourselves.
They’re extensions of whatever we are.
It’s wonderful, the way social media, for example, enables my daughter and her friends to connect with each other at great distances and to help each other out. When one of them’s feeling bad or feeling down or needs help of some kind, they put a message out and it gets spread amongst the community and all of a sudden there’s support for somebody who needs help or wants help.
At the same time, it’s practically a commonplace these days that social media also has the capacity to destroy relationships, to drive kids to far worse problems than they started with. And not just kids, of course, but adults too.
So, these days, I become increasingly concerned about using machinery to distance ourselves from each other and from the problems that we’re trying to solve.
No question about it, machinery gives us immense power to defeat problems.
But it also gives us immense power to create them.
And I’m worried these days that people’s belief that large language models, apart from lots of other things, but they’re like some kind of magic wand. We got to be careful about the fact that they allow us to produce nonsense just as quickly, in fact, even more quickly than they allow us to produce sensible stuff.
The reason for that, part of the reason for that, is I don’t think that people are paying very much attention to how much they’re filling in the blanks.
When you get stuff from a large language model, one of the metaphors I’ve been using lately is it’s like getting advice from a drunk in a bar or from a tarot reader or somebody who practices cold reading as a mentalist.
If you speak to experts in cold reading, what they’ll tell you is that as people on the other side of the cold reading, we pay lots of attention to the hits and we dismiss the misses. And fascinatingly, I did not know this, but cold reading experts point out, not only do they not guess right, they don’t even want to guess right.
Because they’re hacking our cognitive systems.
When they get a miss, they move on really quickly and they go to something that generates a hit.
But if they have too many hits, it doesn’t read properly. It’s a little too suspicious. People start to believe that they’ve got a confederate or something like that.
The really interesting brain hack that they apply is that if they’re wrong a little bit the stuff that’s right will stand out.
That’s fascinating.
I think that’s happening with large language models these days, that people are looking at them quite uncritically and they’re saying, “Wow, this could solve all of our problems and we don’t need humans. We don’t need thoughtful people.”
Now I think to use any kind of software, but especially software whose algorithms were not consciously or deliberately created, is a very risky point of departure.
As long as the humans remain in charge, then the risk becomes substantially lower.
We know this from billing errors that show up in a monthly banking statement or something like we can get on the phone and in a, at least at a sane bank, we can get people to say, “Ah, I see where the error is and we can correct that.” The humans remain in charge.
But I don’t think we should be abdicating decision making to machinery without remembering that ultimately what it’s doing is it’s amplifying policies or it’s amplifying decision making processes that are within our control, that must remain within our control or else there will be substantial harm, loss, damage to certain people. And at a great expense to them, great risk.
So, what would be a useful application for AI and machine learning?
I think one of the most productive ways that we could possibly look at it is to look at these things, not as a decision monitor, but as lenses and as mirrors. And that’s a great way to get into what we’re like and what the world is like.
Then, apply our judgment and our ethics and our morals and our amazing intelligences, not our ability to say things necessarily, but our intelligences, apply those to what we’re seeing and keep the humans in charge.
If we do that, then we can avoid much of the danger that’s associated with these things.
But if we abdicate our responsibility to ourselves and to other people by letting machinery make decisions and classifications for us in ways that matter, we could be facing some pretty big trouble.
So that’s the warning that I would like to leave.
But on a hopeful note, if we stay in charge, we can make glorious advances in so many different ways and make human lives better, not worse.
MH
Thank you, Michael, for a great conversation and for that hopeful warning.
MB
Hopeful warning. I love that. That’s a nice way of putting it. I might have to borrow that.
Thank you for inviting me and for having me on the on the show. It’s wonderful to catch up with you again, because when were you at the class? That was 2006 or something?
MH
Something like that.
MB
That’s amazing. That’s great. It’s been quite a journey for the both of us, hasn’t it?
MH
It definitely has been.
And thank you, audience for joining us today.
Michael and I would love to hear from you on where are your heuristics helping you out, and where are they utterly failing you, and what are your heuristics that you’re finding useful for getting out of that situation?
Thanks and have a great day.
MB
Thank you, Michael. Thank you all.
Thanks for joining us on Uncommon Leadership today. If you found these stories interesting, inspiring, and illuminating, sign up for my newsletter. Use the form at the top of this page. You’ll be the first to know about every new episode of Uncommon Leadership. You’ll also discover how you can build uncommon teams.
If you’d like to chat about doing that yourself, email me, michael at uncommonteams.com or use the contact form above. Thanks so much!