It Ain’t Gonna Fix Itself
Have you ever had that one thing that just festered. It just lingered on broken or inadequate, never rising to the level of immediacy to get fixed.
When I was at Stack Overflow, it was the story of the infamous blue box. It was a visual eyesore on the site where job ads would be posted. It took an f-bomb laced tirade by Stack Overflow’s COO at a company off-site to drive home that fact that the blue box needed to be fixed.
My own brush with this was a database query. One of my first assignments when I started as a software engineer was to build a sales system. The app worked fine, but every so often the system would crash if certain searches were performed. Nothing I tried could resolve the issue, so it was easier to simply instruct users to not run those searches.
I hear countless stories from IT leaders of their own festering annoyances. One bank CIO in Singapore found out two different teams were working on the same exact thing, but the teams had no idea about the other’s work. It is not uncommon to have lots of duplication of work and wasted effort, recalling the quip, “Insanity is doing the same thing over and over again, but expecting different results.”*
A while back in Toronto, I spoke with an Enterprise Architect to discuss a knowledge management project. Like any large organization, they spent an exorbitant amount of money on multiple tools to capture, organize, and share knowledge. Without a cohesive strategy though, their work resulted in multiple disconnected knowledge repositories, exasperating the problem.
The reason we let things fester is the balance between the urgent and important. There is a principle in time management circles called the Eisenhower Method attributed to former US President Dwight D. Eisenhower who said:
“I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent.”
The principle is easily mapped out into a square of four quadrants along one axis for level of importance and a second axis for urgency:
The things in the upper left hand quadrant have to be done. These are the proverbial “house is on fire” issues. However the things in the upper right hand have a huge amount of influence in your ability to handle the urgent and important things effectively, or to even eliminate the amount of time and number of tasks that become urgent.
In The Phoenix Project, that is exactly the situation at the fictional Parts Unlimited. Everything is urgent and the workload eventually piles up to the point that the most important project, the one that is supposed to transform the entire business and leapfrog the competition, gets massively behind schedule and fails on launch. With no process or strategy to manage and prioritize the work, staff became overwhelmed and the system broke down. Planning work was important but not urgent, until disaster struck.
Like workload planning, knowledge management gets squarely put in the important and not urgent quadrant. IT leaders begrudgingly recognize the issue, but are immobilized by the size of the task. Every other tool brought in to solve the problem failed to make an impact, creating a self-perpetuating cycle of apathy.
But ignoring the problem only amplifies the struggles of developers. Not having a trusted knowledge repository creates an untenable situation where developers waste more time, projects get delayed, duplication of effort increases, and code quality suffers. And this has a financial cost to the tune of thousands of dollars per developer per year. On a team of hundreds or thousands of developers, that is a problem that quickly adds up.
Knowledge management is less about the tool and more about the strategy behind leading a change in behavior. That is something that we understand well given the work we do at DEVBIZOPS. The majority of our projects in fact involve helping organizations to tackle the adoption and engagement problem of knowledge management.
How have we done this? This is at a high level the approach that we have used and successfully implemented with organizations:
- Have a strategy in place for building your knowledge architecture. The goal should not be to replace old knowledge, but understand how users engage various types of content and what content they most value.
- Find a group that can be the catalyst. If they acutely feel the pain or involved in a significant amount of knowledge creation or transfer, that is a good candidate.
- Start with a seeding phase. No one want to go to an empty database, so use SME’s and eager enthusiasts to add relevant content to fill out the repository.
- Be systemic and rigorous in your communications. People do not respond to the first few messages, so you must have a continuous communications strategy.
- Ensure you have designated leaders and moderators. This will ensure there is governance over the content so that high quality is maintained.
Behind each of these items are specific tactics and strategies that we use on engagements. Our approach is not to do everything at once, but rather build adoption and value over time. If you are interested in learning more about making knowledge management both important and urgent for your team, let’s chat more about what that journey could look like at your organization.
What are the projects that are urgent and important for you? What are the important and not urgent projects you would like to get started on right now?
*Apparently this quote attributed to Einstein is actually not from him.
Which word begins with “y” and looks like an axe in this picture?
Some of the best sleuthing I have ever seen to answer a question…
We help IT leaders in enterprises solve the cultural challenges involved in digital transformation and move towards a community based culture that delivers innovation and customer value faster. Learn more about our work here.
