In my new corner of the IT world, I’ve been thinking a lot about knowledge management in an environment where people are chronically overworked, under-staffed, and nobody is formally in charge of knowledge management for the whole group. It seems inevitable that, if you have good people working in this kind of context, and if you’re able to retain people for any length of time, it’s inevitable that you’ll end up with extremely competent people who really know their stuff, but who have often managed to keep their heads even near the surface of the water by “doing the work rather than documenting the work.” And this means that processes get heavily siloed, relying on specific people to do things that only they know how to do, and who can certainly do the thing faster than they can train someone else to do the thing.
It’s a tough spot because digging out of it takes time and effort, which are the two things that folks in this kind of context can’t really spare.
I’m lucky to work with extremely dedicated and competent colleagues, and they even carved time out of my job description to build and tend a client-facing Knowledge Base! My goals for the KB are to a) help folks in our community do what they need to do, but also very much b) help our front line staff provide quick and consistent answers to the questions that flood in every day. And particularly at a service where the frontline staff are generally student workers, getting staff up to speed quickly and simply is crucial. Even if our frontline staff weren’t students, I’d still want this kind of a KB. My own analogy always goes back to the way that we used research guides in the library so that even I, a humanities librarian to the core, could help the STEM who came to the general research desk for help. I certainly didn’t know what a Gini coefficient was, but luckily the ECON librarian had a guide on what to do when someone needed whatever-it-was so I was able to provide help and support even in a context where I simply couldn’t know enough about everything. The reference librarian’s mantra is “I don’t know everything, but I know where to find out about it.”
Over the course of the last 9 months, we’ve gotten our KB up and running (and my little “KB Team” and I have learned so much!). And though that work will NEVER be done, I’m also starting to see other knowledge management opportunities on the horizon.
The biggest thing I’m pondering right now is building out “Workflows” in our ticketing and project management system. These are things that would step through flowcharts of choices, tasks, approvals, etc within the ticketing system, and if we’re able to build them such that they step us through our more complex processes they would in effect be the Knowledge Base of Processes. (And yes, I know it wouldn’t be sufficient documentation for our procedures, but it’d be actionable and more than we have available to us right now.) So, for example, what if our processes like hardware request/deployment, hardware reclaim, software/licensing review, change control, Software renewals, certificate renewals, system maintenance, and project request/review (just to name a few) all had workflows in the system?
For things we do less frequently, workflows would help reduce the time we spend thinking “I wonder how we did this last time.” For things we do all the time, they would be safeguards against forgetting crucial steps, and they would be training aids for new employees. For managers and auditors, they would allow for better reporting and visibility for work (and especially for the often-invisible routine operational work) going on in the department. In this way they would complement the already-visible work of answering support questions and working on formal Projects-With-A-Capital-P.
The trick, of course, is getting the time to actually build these Workflows into the system (and then maintain them). And they’d have to be built such that the processes aren’t so complex that they become an added burden on already over-extended employees.
But there’s got to be a sweet spot where these workflows could both document our processes in fundamentally actionable ways, and also help us work more efficiently while shining a light on the mostly invisible labor that makes up so much of our jobs.