Knowledge flows. Prototyping rules. Never leave beta. [2012]

[I wrote this in 2012 for publication in a collection of essays. Reposting it here as a reminder to myself about the evolution of my thinking]

“A life lesson,” said one of my graduate students.

I was leading a class discussion on using design methodology to create technology solutions for organizational knowledge sharing. Design methodology leads you through several phases: observe your organizational environment; craft a design strategy for your solution; prototype the solution to see if your strategy tests out; then implement and evaluate.

“Even when you implement something,” I said during the discussion, “just assume that you’re never done. Every implementation is really a prototype.”

“Never leave beta,” I concluded, adopting software developer language used to describe a not-yet-production-ready product release. You learn from beta releases. You also learn from prototypes. So: Why not just never stop experimenting, learning and adapting?

A life lesson indeed.

This is especially true today when thinking – rethinking – about the role of technology in organizational learning and knowledge sharing. We enjoy an ever-evolving, emergent landscape of technologies that allow us to engage with each other and with content in new, innovative and boundless ways. There is no right answer on how to best to go about this. There is no “done.” We just need to focus on “better.”

Yet still, the trap that I see too many leaders fall into is this: They think about people things and technology things as separate and distinct. People work. Technology gets implemented. Tech is a tool to help work get done. So we implement some new tech tool and rest comfortably, thinking we’re done.

I argue it is important to see the two as inseparable parts of one whole – and that only continuous experimenting leads you to discovering new ways of learning and working.

Imagine a highly productive team gathering. You’re in a room. Lots of great discussion, most of it focused on the work challenge at hand. Some of the dialogue is just informal banter. There’s a whiteboard covered with on-the-fly visuals and notes. You have a project plan projected from someone’s computer (or a spreadsheet, or planning document). You’re taking personal notes on a pad of paper.

The whiteboard, project plan, spreadsheet, document and notes on a pad of paper are artifacts. They are objects created by people. In the scene you were thinking about: Which one of those artifacts was the single most important item in producing the overall outcome of the gathering? Or to put the question in my least favorite form: What’s the ROI of the whiteboard?

And were these artifacts more important than the team dialogue? Take away the artifacts. What happens to the dialogue? Take away the dialogue. Do the artifacts make sense? Imagine a co-worker who is unacquainted with your team’s expertise and the challenge you were working on. She walks into the room.  Can she look at the whiteboard or your notepad and generate the same meaning as you or the team?

Of course none of this can be easily separated. This is a dynamic, social system in which knowledge flows among people, through dialogue and through artifacts. It is a social practice based view of knowledge sharing.

“Artifacts without participation do not carry their own meaning,” writes learning theorist Etienne Wenger.[1] “And participation without artifacts is fleeting, unanchored, and uncoordinated.”

Here’s the punch line: The social technologies that connect us today – blogs, Twitter, wikis, chat, video chat – create a platform for both participation and artifacts. In a boundary-less meeting room.

And when you have people participating in social, dynamic work practices that are as inseparable from the technology as your team meeting was from the meeting room — then the only way you can find out what works is to push out a prototype, see what happens, learn and respond.

So never stop experimenting when it comes to using technology. Ever. Keep your focus on the right thing: How are we moving forward, overall? And not: Have we reached our technology adoption goal? Really – who cares? That’s a milestone. Not a mission.

[1] Wenger, E (2010) “Communities of Practice and Social Learning Systems: the Career of a Concept” in Social Learning Systems and Communities of Practice; C. Blackmore (ed).

2 thoughts on “Knowledge flows. Prototyping rules. Never leave beta. [2012]

  1. I agree. And find it hard to get most people to think this way. They want to be done, to move on to something else. Even getting them to update an individual document, let alone a navigation design layout, is hard work!

    I guess it means I will always have a role to play! 🙂

    Liked by 1 person

    1. Tracy!

      Yep. And I know I am even guilty of having led efforts where the momentum to continue iterating just….fizzles. I might have reposted this essay to remind myself to be better at that, when given the opportunity. 🙂 It does take hard work and discipline – not just for yourself as a leader, but gaining alignment with a lot of other folks.


Comments are closed.