screenshot of thumbnails of two excel sessions saved within Microsoft OneNote notebooks

For a little more than a decade, taught a number of “corporate education” courses with the intention of helping to raise the floor of internal teams as it related to content management and data analytics. One of the more surprising bits of information learned across the years of doing this was a widespread inability to distinguish outputs from outcomes. Some would attend the sessions hoping to “get out of it” a shape of understanding an application for a specific output. A few would have higher level goals akin to managing reorganization and a changing strategic landscape; and these sessions were looked at as helping them discover insights which they could use forward. And a few would be there to just look for “how to do” a thing…

…for better and worse, Excel, SharePoint, Microsoft Project, and other applications tend to have these kinds of shared experiences.

Over time, the shaping of each session evolved from “here’s how this works” to “here’s how to translate what you need to know into what this tooling offers.” And largely, this evolution was successful in moving individuals and teams forward in their use and understanding. However, there was little actual innovation happening with these systems or organizations. An overall assessment of the work led to the disappointing discovery of a lack of preparedness to conceptualize more than it was a lack of ability to use/do a thing.

Part of the shape of solving for a particular issue, or driving towards a desired outcome, comes from the ability to conceptualize various factors (the problem, related conditions/issues, the impact of the outcome, etc.). Many intuitively arrive at this conceptualization through some kind of adopted process - more or less defining the solution by the process they are using rather than by the outcome which was conceived. Others may only see the output as the solution, limiting themselves to other aspects which usually ripple from their actions. In the midst of teaching “how to use…” we discovered a lack of being able to read the entirety of the story (or conceive a new story) and reoriented the sessions to teach towards conceptualization versus simply doing.

We did this through a layered narrative and outlining approach. Using macro and then smaller outlines (in each section) to demonstrate the shape of thinking which will guarantee a desired outcome. For those persons who might have come into a session already skilled in an application, such an approach freshens their skills and grafts a newer semantic language to their own. For those who might not be skilled in an application, the bandwidth required to learn and skillfully use the application will overcome them at some point. These method gave them a means to “clock out and then clock back in” with anchoring - helping them to create a new topology of knowledge rather than simply copying the instructor’s notes.

Conceptualization - a shape of sensemaking - is an old-new technique. We want people to be able to own and shape knowledge artifacts in such a way they are understandable, (re)usable, transferable, and (to some extent) not limited by time. Frameworks for learning which do this are more valuable than the applications themselves because tools change. Regulations around some tools change even more drastically than the tools themselves at times. Being able to create pathways towards outcomes which survive a likely destruction of the original conditions is something of a challenge and a superpower.

Think about how often you’ve had to relearn a concept, versus how often you’ve had to simply reapply it. If you had to relearn a concept, then your framework wasn’t as malleable as you think. When you find folks grappling with “how do I use this application, it has changed too much,” then you are seeing their lack of flexibility and agility. Where folks are more flexible and agile, you’ll see another type of wave develop - one which often turns into no longer accepting mere outputs as the solution, but as elements to measure the complexity of the outcome.

In a few of those old sessions, people came back because they didn’t actually conceptualize the first time around. They only got “it” when they divorced the problem of “knowing the application” from the thing they were actually aiming to do. Then the sessions made sense, and they were able to craft the story forward which enabled their teams to persist in the midst of change. Think about such things the next time you are offered a course or certificate - what does that actually prepare you to conceptualize? And are you capable of the outcome, not just iterating outputs.