Run the shop vs improve the shop

I don’t suppose that the dilemma or balance between “run the shop” activities and “improve the shop” activities is special to KM. It’s a consideration for all organisational functions, and, indeed, for all businesses. Just what proportion of your focus and effort should you put into each side at any given time, or over a period? I think this is one of those instances where there’s more to say about the question than the answer – because the answer, your answer, will always be context-dependent. And if this equation isn’t special to KM, the kinds of things being weighed up probably are.

One thing that’s different is that we, as KM, are less well-established than other functions. Finance has had literally hundreds of years to hone its routines and standards and finance departments are typically focused on smooth execution with only sporadic focus on making major improvements, such as a new IT system. Other established functions such as HR and IT are closer to that position than KM, which is not only still a young discipline in the world in general, but is very often still establishing itself across organisations. We’re still inventing and testing it at the same time as trying to both deliver a bau set of services and implement new structures, measures, processes and systems – often brand new, not just ‘new to us’.

Of course the best balance is where the input cost and effort needed to “improve the shop” pays back enough and soon enough to more than cover any loss of focus on “run the shop” in the meantime. When tortoise beats hare.

That’s how I try to think about it: Will the time and effort input needed to build community, build content services, shift the needle of the culture and so, will that pay back far more than spending that time on more tactical needs instead. My approach is to divide my focus between the two sides and also try to do both things in one.

Dividing my focus between “run” and “improve” may sound obvious but I find that is very often not the approach taken: Many, many times over the years I’ve been told by different functional people that they couldn’t spare time to help with a need someone had that day because they were focused instead on a longer-term project. And, conversely, other people never improve process but concentrate instead on executing the process as is. So it’s certainly not obvious to split your time and focus between today’s needs and future improvements.

There’s also a middle way, which is to blend the two. If someone has a specific need today, can I address it in such a way that it becomes part of a solution I want to build? Very often yes. I can turn my answer to them into version 0.1 of a guide that I can publish and improve next time there’s a call for something like it. I can use a request to do something outside policy as an argument to seek to modify the policy, rather than just grant an exception.

Mostly the customers for / users of / participants in KM services and solutions wake up to their need precisely and only when they have that need. Responding to today’s need is hearing the signal for what is really going to be useful. Seeing the wider pattern of all the different needs and ideas is joining the dots into a strategy that you’re building towards – improving the shop by running the shop.