Leading-edge executives are no longer thinking that they are a healthcare company, a bank, or a retailer that happens to use software to support the operations of their business. Today, those forward-thinking executives recognize that they are actually software companies that happen to provide healthcare, banking, retail, etc. They are moving from an operating mindset to an innovating mindset.
If you think about it, most companies are operating, not innovating. What does that mean? It means they are focused on operating within that which is already existing. They are trying to optimize what they already do rather than reinvent what they do. But is that a bad thing?
I venture to guess that having more companies innovating would be better. So, why are there not more companies innovating? I suppose one reason is that innovative minds are not as common as we would like. Another thought is that we might find more innovation if given the chance.
Before I move forward with that last point, let me clarify what I am not saying here. I am not saying that you and your team(s) are not creative, are not finding better ways of working, and are not producing new products that are amazing. I like to think most of us are doing that. But let’s be honest, most of us are not innovating at the level that makes the news.
Picking back up on the previous thought, what do I mean when I suggest we could be more innovative if given the chance? Despite the fact that your team may be producing something valuable, a software product perhaps, innovation may be stifled in lieu of focusing on maximizing operational capacity and flow. Are you seeing where this is going?
Agile is the focus of most software teams today, with many trying to follow Scrum or Kanban methods. Both are very different approaches for moving ideas through to deployment, but practitioners of both have glommed onto the pursuit of maximizing capacity and flow. In Scrum, teams are trying to improve velocity, which is the arbitrary output capacity of a team. In Kanban, teams are trying to eliminate delay and move individual work items as quickly through the flow as possible. The “common wisdom” approach of both is to do more in less time.
The blog, The Unintentional Intentional Distortion of Agile, pulls an excerpt from my book, Pursuing Timeless Agility: the Path to Lasting Agile Transformation, to suggest that optimizing flow is important, but the context of what you are optimizing is more important. Traditional management theory carried forward into software project management, which has not been very effective. That same theory carried forward into attempting to work by Agile practices, and the results are even worse. It is a misalignment of the greatest magnitude.
Traditional management suggests that managers know best and that their people are to carry out the processes and directives of those managers. The workers are evaluated based on how well they carry out the manager’s will and by how “productive” they are. How that translates into today’s software development is via velocity. Actual vs. planned is still compared. Finishing what was planned in the timeline given is the measure of success in many organizations. Industrial age mentality in a digital age does not work. See the blog, 3 Common “Agile Metrics” Mistakes.
Software is knowledge work, not manufacturing work. The value is more in the thinking than the actual coding. When teams are evaluated by outputs, by how much gets done versus what was planned, it leaves smart people no time to consider what else could be better. When so much pressure is put on meeting “productivity” measures, organizations waste the money they are spending on these very talented people because their time is spent producing to a plan versus innovating.
Traditional management thinking believes that innovation comes from management. The management of the organization comes up with great ideas and tells the developers what to build and how. This actually happens a lot, and I believe it is arrogant and foolish. This line of thinking basically treats developers as machines that output to the specifications of the “smart” people. Steve Jobs once said, “It doesn’t make sense to hire smart people and then tell them what to do.” If you truly want to innovate, you must include all your people, and you must give them space to do so.
Innovation requires thinking. Thinking means code isn’t being output and made production-ready. Experimentation is also part of innovation. Something is being developed and tested to prove out assumptions, but experimentation is not outputting the “plan,” thus velocity suffers. How much time are your teams given to just experiment? Many call these “hack-a-thons.” It is time away from normal operational work and projects, and provides free time to your smart people to explore new ideas. Does that happen in your organization?
Good employees are rarely doing “nothing.” They are always thinking about better processes and better products to solve real problems. Innovation is only going to be a norm in your organization when you give your people the time, space, and freedom to think and explore. So the next time you see someone at work sitting back staring at the ceiling “doing nothing,” they may very well be producing more value than actually “working.”