Methods, mechanics, approaches

Why doesn’t ‘best-practice’ work as best-practice everywhere? And what is it that makes a skill a skill?

For me, this one goes way back to work I did for my Masters degree, nigh on forty years ago. And to me, the answer to both of those questions is the same: methods, mechanics, approaches. But we probably need to do a brief discursion in order to get there.

The quick answer to the first question is that ‘best-practice’ is a method – a way of doing something. And it would and should work well everywhere, if everywhere is the same. Which it’s not. That’s the catch.

‘What works’ is not just about the content, the supposed ‘best-practice’: it’s contextual too. Where things are the same between the original context and this new one, the ‘best-practice’ will probably work well. Where they’re not the same, it may or may not work well – but there’s no way to tell that from the ‘best-practice’ itself.

So in any given context, we’re going to need skill and experience to work out what’s the same, and what’s not, so as to work out what parts of some ‘best-practice’ will work well, and what might not, and what to do about it.

[In the enterprise-architecture space, TOGAF is a useful example of that type of ‘best-practice’. It is a good summary of best-practices for the IT-related parts of enterprise-architectures: yet as any experienced TOGAF practitioner will tell you, it always needs to be adapted to the context of the respective enterprise. It’s not something that is likely to work well ‘straight out of the book’: hence why a good TOGAF training-course with experienced trainers is far more important than a ‘by-the-book’ certification-exam.]

Which leads us to that other question: what is a skill? What is it that makes it any different from straightforward training?

To which the answer is the same: methods, mechanics, approaches.

A method is a way to do something. Almost everyone will focus on methods, because in the end that is how things are done. But the catch is that methods don’t just ‘arrive from nowhere’: they’re created by someone (or, occasionally, something), in response to a context. So to understand methods, we need to understand where they come from.

The simplest way to put this is that some aspects of each context will be the same as in other contexts, and some are different. Some aspects of a skill are the same for every person, and some are different. In that old Masters research, I summarised those ‘same’ aspects as the mechanics of the context, and the ‘different’ parts as the approaches. Whether the context is an enterprise, a technical problem, or the skills of a specific person, a method is a context-specific resolution of the ‘objective’ mechanics that apply in that context, and the ‘subjective’ approaches to that context. Or, in visual form:

That’s why we have a definite sequence for skills-development, from trainee, to apprentice, to journeyman, to master. We can even describe with some precision how long it takes to develop each level of skill: respectively, a typical minimum of 10, 100, 1000 and 10,000 hours. The methods can change quite radically as we develop along that path: “don’t do as I do, do as I say”, says the trainer to the group of ‘newbies’, as she sorts out a problem with a method very different from the one she’s just taught. To actually do something, we’re always using some kind of method. Yet it’s how each method arises that’s where it gets interesting.

In effect, machines are taught methods, or have some kind of method built into their inner workings – and that’s usually where they stop, because in most cases they don’t have any means to learn, or to self-adapt to different contexts. By contrast, people can learn, and do learn: we may have specific methods we fall back to for much of the time, but overall, the ‘toolbox’ of methods we use will keep changing all of the time.

Perhaps the key point there is that the mechanics of the concern are the same for everyone and everything; the approaches aren’t. We each approach each context with our own specific mindset, worldview, paradigm, a sense of what is possible and what is not – or, in skills-work, perhaps more a sense of what is possible for us to do, and what is not. And what works for us is not necessarily what works for anyone or anything else. Or it may be. Or may not be.

That’s where all of this starts getting a bit ‘meta-‘, because we need skills and experience to understand how to change our skills and experience; we need to ‘bootstrap’ our worldviews and assumptions with worldviews and assumptions that can break out of the box of a given set of worldviews and assumptions. Kinda mindbending, of course, but people are surprisingly good at that – especially if they don’t actually notice at the time that they’re doing it! 🙂

There’s also a useful crosslink here to the SCAN sensemaking/decision-making framework, in that, in effect, the mechanics of the concern sit on the ‘order’ (left-hand) side of the Inverse-Einstein boundary, whereas the approaches sit on the ‘unorder’ (right-hand) side.

And methods, in turn, kind of traverse downward through the vertical axis in SCAN, from analysis and experiment to develop the method, at some distance in time away from the point of action; and the method is then used when we’re at the point of action. A key part of any learning-process is to note the differences between the method we planned to use; the method we actually used at the point of action, and what happened when we did; what was the source of each difference; and what we can learn from this to do differently next time – in other words, the classic US-Army After Action Review.

So, whenever we look at applying some form of ‘best-practice’, or using someone-else’s method in our own work, we need to ask:

• what are the mechanics of this – the parts that are the same between each person, each context?
• what are the approaches to this – the parts that are different between each person, each context?
• what similarities and differences  in methods do those mechanics and approaches imply?

Just another possibly-useful idea to play with, perhaps? Over to you, anyway.