As a manager seeking to improve my game in managing software developers, I’ve taken the stance that software development is knowledge work. I therefore keep an eye out for useful information about managing knowledge workers, not just software developers. The book, Reinvent Your Enterprise Through Better Knowledge Work appealed to me on that basis.
Jack Bergstrand makes some solid observations about the need for productively managing knowledge work. One being that the half-life of knowledge continues to get shorter. This places demands on knowledge workers to learn faster, interact better, and produce better and more accelerated results. (This struck a chord with me, since we’re always looking to produce “better software, faster,” and the rate of technological change has been significant during my career.)
And while this wasn’t a software development book, another observation was spot-on: Knowledge work is how individuals and groups use ideas, expertise, information, and relationships to get things done. It includes tasks such as brainstorming, analysis, project management, and personal coaching.
These activities are exactly what we’re doing with our Agile/Scrum development process. We want individuals to collaborate and share ideas and expertise.
Bergstrand notes that knowledge work actually needs to be managed better than manual work because there are so many ways for it to go off track and become unproductive:
- Too many meetings that produce too few decisions and actions
- Competing internal priorities with no mechanism for resolution
- Studies that are completed and put on the shelf
- Projects that get started but are never finished
- Projects that get started but are not finished on time
- Projects that never get started but get talked about every year
- High executive turnover that causes frequent changes in direction
A system to manage knowledge work requires both a shared framework (shared mental model) and an explicit process. The framework is needed to get everyone on the same page. The process helps people manage their knowledge work more productively and sustainably. The model needs to simplify while also being robust enough so that knowledge work tasks can productively self-organize and the architecture in a variety of situations and under various conditions.
It is usually productive to write off underperforming products, operations, and orientations at the same time an organization is moving forward with new things. This can help establish new standards of performance.
Organizational hierarchies produce known problems, but it is not productive to be anti-hierarchy. Working without a clear organizational structure is the most unproductive situation of all.
Overall, this book was well-written, and provided me with an excellent, generic perspective on managing knowledge work, but less so on managing knowledge workers themselves.