As part of the wider reading and research I’ve been doing around the whole subject of performance support, a month or so ago I read a book by Marc J. Rosenberg called, ‘Beyond E-Learning.’ It was published in 2006 to much praise.
My take is that it’s a kind of predictive manifesto for L&D at the start of the internet age. In the book, Rosenberg lays out a future framework for how L&D could work within a business and embrace new technologies to become more than just the providers of training.
Some of it, inevitably, feels very dated. But some of it is still remarkably relevant and prescient. The framework he describes includes elements of performance support, which is what led me to the book to begin with.
Without skimming through and finding the exact page and the exact quote, I’m going to paraphrase a couple of points Rosenberg makes about performance support early in the book.
The first point is along the lines of performance support being useful because it means people can get a job done with just enough help to get by. The second point arising from that is sometimes people can look like they know more than they actually do.
At the time, both of those thoughts caused me to put the book down and spend a bit more time thinking about what I’d just read. I wasn’t entirely sure I agreed with the first point; and I wanted to think through some of the problems inherent with the second point.
As it turned out, both of these points became very real for me this week while I lived my very own performance support moment of need. Let me explain.
I’m working on a couple of simple custom GPTs for clients as small proof of concept projects. Both are examples of the output an L&D department might produce for their learners if they were using PerformaGo. Not an example of the PerformaGo tool itself. That comes later.
As a quick aside, if you have an idea for a custom GPT for your learners that you would like some help with, let me know.
So, I started both projects using an existing software tool that can produce very simple custom GPTs. But after several frustrating attempts to turn these proof-of-concept ideas into a reality, I realised the tool was simply not up to the job and I needed a re-think.
By the way, my policy for the diary is that I’m mostly not going to name names when it comes to other software applications that I’m using. For example, I could write some horrible things about my frustrations and experiences with this application; but that really wouldn’t be fair because I was trying to do something that this application was never really designed to do.
While a re-think is never a bad thing, deadlines that I really wanted to keep were fast approaching. I was feeling a bit pressured and stressed.
I had to accept that I’d spent quite a bit of time and effort going down a software road that turned out to be a dead end. Also, I had to accept that a single piece of software wouldn’t necessarily meet my proof-of-concept needs. This meant getting my head around a more technically complex set up (involving three separate applications) rather sooner than expected.
My performance support need was pressing and real.
So, the good news? The proof-of-concepts got done. The deadline was met. Everything worked. Everyone seems happy with the results – me included.
There isn’t any bad news, per se. But there are a couple of interesting insights from testing Rosenberg’s earlier points to destruction.
First point, I certainly got the job done with just enough help, just when I needed it. That felt like a real achievement. Secon point, had I talked about what I had done to someone less knowledgeable, I would definitely have appeared much smarter than I was.
Here’s what I found most interesting. At a conceptual level, I absolutely understood what I had done. I could give you a convincing high-level description of what I had done with each of the software applications and how I had linked them together. However, at a detailed level, if you asked me to go ahead and explain (or repeat) what I had just done, I would have barely had a clue.
In the moment of doing, I was merely following steps that were being provided to me, with no real understanding of what sat behind each step or how it connected to those high-level concepts.
It was a weird and frustrating experience. I was skipping around three unfamiliar software interfaces, clicking and selecting here, inputting there, simply because the instructions told me to.
Needless to say, I spent a long time going back over what I been instructed to do. With the help of ChatGPT, I started to understand the detail of the earlier instructions.
By the time I finished reviewing what I had just done I was much happier. I still couldn’t repeat what I’d just done entirely on my own; but I would have needed much less help second time around.
A couple of other important observations here.
First, I was highly motivated to get the job done. Without that motivation, there were a couple of moments where I would surely have given up.
Second, I was working well outside of my domain comfort zone. It was stuff that for me, felt quite complex and somewhat difficult.
So, is Rosenberg’s idea of ‘just do it and don’t focus on anything else’ performance support a good one? For simple tasks, it’s probably okay. Although, my guess is that even with simple tasks, some people would flounder and feel frustrated.
But my specific experience suggests that in more complex situations, pre-performance support training and context-setting is still essential.
A pressing deadline forced me to operate in reverse order. Performance support first. Really understanding what I’d just done second. And no question, the performance support first approach worked. It got me to the finish line within the desired timeframe; but it also left me clueless.
I had to go back and do the self-directed equivalent of training and context setting to ensure I could effectively repeat the initial performance.
For me, a massively useful experience on multiple fronts. And, I hope, some useful insights for you, too.
Until next time…
