Yesterday I described the moment of recognition of a problem, which tends to happen in the upper-left corner of this table:
When I perceive a problem during testing, it’s my job to let people know about what I’ve found, and to arrive at a shared set of feelings and mental models about the problem, represented by the lower left quadrant. That is, I want to move from experience—my private, internal, tacit mental models of the product—to the conclusion of successful conference, such that my clients understand what I’ve observed and why I think it’s a problem; and such that I understand their response to the problem, even though that doesn’t necessarily mean that the problem will be fixed.
I might not have to talk about the problem. Sometimes I can get the message across tacitly, without actually telling someone explicitly what the problem is. If I’ve been working with people for a while on the same project, I might be able to communicate without using words at all. In a society or culture, people develop collective tacit knowledge, an understanding of what things are and how things are done in that culture. Collective tacit knowledge is not contained in any one person’s head, but in the social group, and in the relationships between the people in it.
From the previous post, recall the cropped fonts that surprised and amused me.
A developer is walking by. I gesture or grunt something to get his attention. “Yo!”
The programmer replies, “Huh?”
I turn to my screen as he looks over my shoulder. I have the Windows Change Font Size dialog open. With a glance, I can see that he sees it too, and that he’s watching. I point to the Large Fonts radio button. “Hmmm?” I open Acrobat’s File / Properties / Additional Metadata dialog. We both see this:
I say “Euuugh!”
The programmer peers down at the screen, and I can tell that he sees the cropped font problem just as I do—just as you do. “Euuugh!” he says. “Ugh!”
“Mmmmm!”, I reply. He shrugs, sighs, rolls his eyes, and walks off towards his desk. By his manner and his expression, I know that he’s intending to fix the problem, even though we’ve only communicated in grunts. I’ve just had a conference with the programmer, with the communication structured and framed by our shared feelings and mental models; by our collective tacit knowledge. I didn’t have to describe the problem or cite an oracle. Without having exchanged a single word intelligible word, we’ve arrived at our destination. We’ve gone straight from my tacit, private feelings and mental models (experience) to shared feelings and a shared understanding about the problem (conference) and that has prompted some action. A bug is going to be fixed! Huzzah!
Of course, such simple and straightforward exchanges don’t happen very often. Far more often, there’s more work to do. We’ll talk about some of that in the next post.
3 replies to “Oracles From the Inside Out, Part 3: From Experience Directly to Conference”
Nice post and nice method!
While reading this post I came across your table picture which is for some reason in my browser is showing as it somehow got much enlarged in its right side and intersects the right navigation section.
My first response to this according to this table is that I observed something out of my mental picture and my mental picture tells me that one element should not be intercepted with some other in way that the two elements should not collide and became inseparable in value.
And then the feeling “Iiiiich” 😀 .
Michael replies: Which came first? The awareness and application of the model and analysis? Or the feeling? (In any case, I’ve fixed it; thank you!)
There is a lot of “conferencing” going on here:
Forgive me, it was just too easy.
[…] Blog: Oracles From the Inside Out, Part 3: From Experience Directly to Conference – Michael Bolton – http://www.developsense.com/blog/2015/09/oracles-from-the-inside-out-part-3-from-experience-directly… […]