RSS

Tag Archives: consulting

Anything Interesting Is Educational, or, Abstraction Is For Experts

It takes me a few days to work through a concept sometimes. I have an essay about the central metaphor of gaming groups, for instance, that I had planned to put up last week – I’d say I understand about eighty percent of what I am trying to say, and the text still needs some reworking. Fortunately, I have a mini-insight, a shorter-order idea I can put up in the mean time.

I collect a lot of important concepts in my daily life. Some times, I notice it more than others. Recently, I was digging around in the blog of the game designer behind the recent kickstarter project about a lego-robot tabletop war game, Mobile Frame Zero, and I happened across an entry on trying to sell genre-appropriate roleplaying games at a horror convention, without success.

You can read the entry I’m talking about here, on Vincent Baker’s blog. It’s an interesting read, and I learned about some games I’d like to play – but the real treasure, for me, came in a followup post linking to another blog’s take on what might be done to improve the salability of such games to the horror-convention set. You can find this insightful post here.

The key insight, the thing I’m most glad I learned, is this:

It’s not just that specific situations are more engaging – they’re also much more useful for people to learn from.

Abstraction works for experts, because experts already have the mental framework to interpret and understand the abstract ideas being presented. They also have a mental bank of examples to draw from, so the abstract ideas very quickly get fleshed out in their minds. Novices have neither a mental framework nor a rich set of prior experiences, so the abstractions remain just that.

Friends, I have been struggling with an abstraction is for experts problem for a few months, both at work and in the consulting I’ve been doing for Alpine Valley School. If you have been involved in either of these settings – or if you are one of the people I vent my frustration on this topic to – you may be able to guess what I am talking about.

There is a vital distinction that underlies some important thinking about elements of an organization that are not working, and it is my tendency to communicate this distinction as an abstraction in the hopes of being able to use it immediately in discussion. When I do this, I say something like, “There’s a difference between process and procedure, you know. A process is what actually happens – a procedure is what we write down, or what we say happens.” This comes up because while one can “follow” a procedure, if you say someone is “following” a process, I believe it means follow as in “he follows politics closely” or “follows what I’m saying” – or doesn’t, as most often seems to be the case when I bring this distinction up.

A process includes elements you can’t control or maybe even perceive, or at least haven’t yet. A process is something you can study, observe, model in your mind, design and then attempt to implement – but it is not something you can “follow” in the rote sense of doing the proscribed steps. Digestion is a process. Construction is a process. Learning is a process. Following a standard set of steps in a standard or expected situation is something else. Standard Operating Procedure covers it – this is something I abbreviate to just “procedure.” You can be following procedure, or not. These are valid constructions that invariably mean what people think they mean. Procedures are part of, and describe and influence, some processes. But they are not the same.

The reaction I typically get when I bring this up is, “Oh, that’s just semantics.” People resent being distracted from what they’re trying to fix or plan, want to get right to do the doing, and are more than happy to dismiss the distinction I’m trying to introduce as a waste of time. This can be incredibly frustrating; here I am, working with smart, interested people, and I need to make some important points about what we’re discussing – points that I believe they will find useful – and I can’t, because they are uninterested in the distinction that enables understanding of the points I want to make.

For instance, changing the procedure doesn’t necessarily create the change you want in the process, and in fact the process as it happens right now may not even closely match the procedure you are trying to assess and modify. These are ideas that can lead directly to stronger understanding of a situation, and to a better grasp of where processes are breaking down, especially when people are using the same word – “process” – to refer to both what we say we do and what actually happens. Ideas forced to live together under the same title tend to merge and become difficult to extract, to come to have reduced distinction in the mind of the individual co-titling them.

Here is where the insight that abstraction is for experts comes in. It’s not that the people I’m working with don’t want the point, necessarily; it’s that the abstraction is, at best, interesting but unrelated when I introduce it in this way, and the “just semantics” reflex closes off further exploration with a wave of exasperation. People don’t want to waste time in meetings, and most people identify semantic discussions as a waste of time. I don’t happen to share that particular valuation, but that doesn’t mean I can get an exemption from it.

In discussing this problem with Aubrey (a damn fine software tester/quality analyst who happens to be my sister), I found that while she recognized my irritation, she steadfastly refused to validate my frustration. I wanted very badly simply to complain – perhaps because I saw the problem as tragic but inevitable. Aubrey knew better – she understood that it wasn’t that the idea was impossible to communicate, it was that it wasn’t concretely connected to the discussion in the minds of the people I was trying to help, and so felt like a distraction.

I bristled. I tried to prove her wrong in a brief role-play in which I took the role of the (I was sure) unassailably uninterested party. Aubrey was right, and I was wrong; she was able to communicate the points I had wanted to make without having to present the abstract semantic distinction up front. By sticking to specific, concrete points that edged around the semantic issue and using alternative language like “what we have written down” and “what we are actually doing,” she presented her ideas in a way that left no opening for my prepared rejection of semantics to even enter the conversation. By maintaining the distinction between process and procedure in her own speech without calling explicit attention to it, she laid the groundwork for introducing the abstraction of the semantic points to people who would already have specific, concrete ideas to attach the floating abstraction to – if, points having been made, it was necessary to bring the abstraction back into it at all.

I was the one who introduced her to the idea of the distinction between process and procedure in the first place. (To be fair, she was the one who introduced me to the work of James Bach, which is where I got it from.) When I introduced it to her, I simply gave her the abstraction. I wanted to tell myself that the reason that worked with her and it didn’t work with my colleagues was that she was an Alford, and Alfords are better at this stuff – but of course, it doesn’t work that way. She just happened to be an “expert” in semantics and testing, areas rich with experience and mental frameworks directly related to the concept I was communicating – so the abstraction worked for her. The other people I was trying to communicate the abstraction to were not experts in related areas, and lacked these resources – so my attempt to communicate an idea that I understood so vividly collapsed, because they simply couldn’t see the relevance.

This was my fault, which is the conclusion I did not want to reach. Had I considered or intuited the idea that abstractions are for experts, perhaps I would not have needed to consult Aubrey’s hard-earned expertise in communicating these sorts of concepts.

Aubrey had solved my immediate problem, but I didn’t understand why I had the problem in the first place until I happened on that passage in a post by an author I’d never read before about selling horror roleplaying games to non-gamers.

This is how a great deal of learning happens: by accident in the specific instance, but by design in the general habits. I did not intend to learn this particular thing (how could I have?) but my habits of analyzing my problems, discussing them with smart people I respect, and deeply pursuing any subject that catches my interest allowed me to make a mental connection that I hope will be of great utility to me in the future.

 

Tags: ,

 
Follow

Get every new post delivered to your Inbox.

Join 205 other followers