Share what you really do in your role

I think it’s well understood that the senior management in a large (or possible any-sized) organisation most probably doesn’t know how the work the company does is actually done. A ‘back to the floor’ exercise in which the senior execs take on a role at shop-floor level for a few days would expose that.

What I find has been less acknowledged is that colleagues working together in different stages of the same process also most likely don’t know precisely how each other really does their work. Think of any business process: sales, product development, customer service, joiners/leavers – really any process with hand-offs between different roles and mortals who each perform a different step or set of steps in the process.

• I’m suggesting today that that kind of conversation, that brings people together from throughout the process to share the facts about how they each actually do their jobs is a good idea to do:
• It’s likely to be interesting, surprising and illuminating – the participants will enjoy this (that is, at least, what I have found)

It’s easy to do – there’s no prep. needed. If people do need to actually show rather than tell (often good, but not always necessary) it’s best they show and narrate the real work rather than producing separate presentation material that would require preparatory work (do this “working out loud”)

I’ll give just two examples of what you’re likely to find and how this process quickly leads to benefits and value.

1. Hidden factories: You’re likely to find that various actors at different stages of the process have routines and solutions that they have developed for themselves to snag difficulties in performing the process that are not formally recognised, have never been documented and were likely unknown to anyone else. For example, say a process requires an actor to view a piece data in an IT system, check that with reality (e.g. has the status of the case changed in real life?) and then update the record in the system. You may be surprised to learn that that person in fact copies the data to a spreadsheet in their personal filing where they record the sub-stages of investigating the cases before they update any central record: perhaps they have to check with numerous other people or look at other data, and perhaps that process has delays and loops in it in real life that nobody ever knew. Exposing this might lead to different solutions including maybe eliminating steps that actually add no value or perhaps incorporating vital new steps into the formal process and IT system.
2. Snags and problems: Only the person who actually performs the process step knows what goes wrong, what is difficult, what other needs are not recognised in the formal process or IT system. By sharing these sometimes the whole team working together can make improvements: perhaps the downstream snag needs an upstream fix (for example, better input data quality) that can only be made by another person, in order to eliminate the need for more complicated processing downstream.

I’m also going to suggest that this is best approached as a peer-to-peer discussion, or, that if managers and supervisors are involved too then they approach it with the right spirit of curiousity, learning and improvement rather that fault-finding and blame. I think most will do this right – but it’s worth considering in order to avoid it all taking a wrong turn.

Sharing with each other across a whole process what each person really does in their role is an easy, fun and productive kind of knowledge sharing.