Knowledge work is especially misunderstood for product development. Say software engineering, for example. Business struggles to control knowledge work, and it shouldn’t try.
Knowledge work is misunderstood by business. Business has established itself over millennia in a certain form. Business as a mindset, as it has been mostly practiced for millennia, simply can’t get knowledge work. It’s antithetical.
Business wants answers. Clear answers. Predictable answers. Actionable answers. Fixed answers. Marketable answers. Pragmatic answers.
“And it is also said,” answered Frodo: “Go not to the Elves for counsel, for they will say both no and yes.”
Knowledge work wants empiricism. It wants to go with what works. Change when that changes. Follow the evidence. Adapt. Get things done.
There is cross-over here. It’s not that the two are antithetical to each other. The priorities are. But it doesn’t have to be that way. One of us has to change. And we both know who.
Knowledge workers are good at getting things done too. There is cross-over here. But knowledge workers’ priorities are not about profit. Business needs to get that.
Knowledge work is pragmatic too.
“Is it indeed?” laughed Gildor. “Elves seldom give unguarded advice, for advice is a dangerous gift, even from the wise to the wise, and all courses may run ill.”
Working with knowledge. Working with what is known. Changes over time. Things looks different in light of new experience. In light of new information. From different contexts. It depends. It’s empirical.
There are different ways to approach things. Different choices. Different things to try. It’s not a fixed science. It shouldn’t be. No and yes is ok, it’s balanced. It depends.
“But what would you? You have not told me all concerning yourself; and how then shall I choose better than you?”
All of this has had business losing the plot. It can’t jibe with this. At least, it doesn’t think it can. But it can. It does. It’s doing so successfully already, right now. Things are changing. The old dominant mindset is changing.
I’m not sure how it’s going to play out. The direction things are going seems clear. I’m ok with that. I’m a knowledge worker.
Knowledge workers don’t understand themselves
The biggest disaster isn’t really that business doesn’t get knowledge workers. It basically does, really. It’s just not interested. Or hasn’t been. It has other priorities, and most of what they’ve been saying hasn’t seemed to fit with that.
The biggest disaster is that knowledge workers don’t get themselves. They change what they do to fit with the needs of business. They think that’s the way it’s supposed to be. They’ve not had much choice. They’ve needed the work.
What are we doing about it?
Well, a lot. There are some very cool things going on. In programming and software engineering, for sure. That’s what I know. Things are getting better. Knowledge workers and business are working together, successfully, in amazing ways. Things are going well.
Agile software development methodologies have a lot to do with this. Finding new ways to manage projects that leverage the differences in a space where prescribed plans and fixed requirements have been proven ineffective in most cases.
I think it’s worth noting that they haven’t gone away. They’ve simply adjusted form and been applied differently. All of the concerns that were taken care of with sequential development are still applied with other methodologies, simply at a different scale and implemented differently.
We’re finding better ways to do things. That suit the way knowledge workers do their thing.
Scrum especially is a great example of this. Scrum is a development methodology where work is carried out in two week sprints, with a clear framework for managing the lifecycle, and regular “inspect and adapt” meetings at the heart of the framework. It encourages empiricism and autonomous teams of three to nine.
It’s a great methodology for knowledge-based work. It is not suited to every type of project. It favours clearly defined problems with unclear solutions. Especially complex ones. It is used extensively in software development. But it is also being applied in knowledge working teams across a diverse range of industries with great success.
The popular alternative to Scrum is Kanban. This is a more adaptable approach in terms of the workload it can handle. It is similar to Scrum in many ways, but without a fixed cycle. Tasks move through a pipeline, with an approach to limiting the quantity of work in progress at any stage, and suited to dynamic teams that go where the work is needed.
Kanban suits known solutions to changing problems. It favours simpler problems than Scrum. Scrum and Kanban can be combined in various ways to create hybrid approaches. Along with other methodologies and techniques, they head a catalogue of approaches that can be combined as needed for a particular team’s unique needs.
To round out the picture, projects can use a Continuous Delivery model. This is often implemented as some form of DevOps, although elements of Scrum, Kanban, or both are often included. Agile and DevOps are often seen as opposed, but this is more of a separation of communities than a separation of ideas. They are very much based on the same core principles and have a lot in common.
Continuous Delivery fills the needs of projects that tackle unknown solutions to changing problems. It is suited to anarchy. It adapts quickly and goes where the work is needed. Solutions are delivered quickly and everything is dynamic. Perhaps this is why the primary focus of the space is so different to agile methodologies in general, even though they are really complementary parts of the same space.
Modern product development methodologies, as outlined above, and properly implemented, are highly effective in bringing business and knowledge workers together in an environment that enables both to thrive.
This is encouraging, as business has historically had a rocky relationship with knowledge work, especially in the modern programming and software engineering space. New working practices and understandings are changing this, one team at a time.
For more on this topic, read how I applied an agility to my writing process, along with ideas for how you can apply it to your personal projects.