Perhaps no question has the power to stop executives and software managers in their tracks faster than, “What are you doing about innovation?”
You can’t blame them, as there’s really no blueprint for establishing the processes, mindsets and disciplines required to generate the innovations that consistently lead to high-impact results. Traditional waterfall methods of software delivery definitely won’t help produce them.
But there are steps leaders can take to drive innovation into the everyday processes of their organizations: Start with something meaningful to the business, limit work in progress, create real value and then scale the solution. Starting small instills teams with the discipline to stay focused on tasks, move quickly and avoid bigger, more costly plans that often produce few results.
In our work with clients, we’ve identified five steps that will help businesses dedicate more time to innovation:
- Focus above the value line. The first step to making room for innovation is to make a list of all the work your team is doing, and then identify the activities that are contributing to its core mission. Be ruthless about alleviating work that isn’t imperative to your team’s primary goals.
Focusing your resources also means leveraging existing technology rather than building from scratch, with particular attention to open-source solutions or technologies that comply with open standards. A modular, prebuilt option may cover 80% or 90% of your needs, and free you to focus on tasks with a direct relationship to revenue and creating new value.
This step may appear obvious, even welcome, to many people, but software engineers often feel compelled to build every network and line of code themselves. Doing so, however, often results in a product whose only customer is the engineers who built it. Similarly, relentless prioritizing doesn’t come naturally to every organization, but it’s essential. As Steve Jobs famously said, “Innovation is saying no to 1,000 things.”
- Stay independent but connected. It may seem like developers would be most efficient if they could eliminate dependencies on other people. This just isn’t possible, however, in today’s world of microservices, in which developers work independently but are also interconnected with each other. This leads to the common frustration of relying on functionality from teams that fail to deliver within their previously communicated timeline. Faced with this problem, many teams will choose to do what’s right for the customer by implementing needed functionality themselves. While this is to be admired, it postpones fixing the real problem.
Fixing the problem requires dismantling organizational silos, and holding teams accountable to their deliverables. Some useful best practices include:
- Align and share goals: Most teams are well intentioned and strive to honor their commitments. The failure to deliver is often a result of misaligned goals. One team might have had a different set of priorities, or their priorities conflicted in the first place. By aligning goals from the beginning, teams can focus on shared priorities.
- Set realistic timelines: Teams are often overly optimistic in their feature costing, or they lack clarity on how a specific functionality will be implemented. Regardless of the scenario, teams can ensure adherence to set timelines by being realistic and accounting for all the work. This means de-risking functionality prior to signing up to implement a feature. By taking this upfront step, they can avoid schedule uncertainty that only becomes apparent when it’s too late in an iteration to mitigate.
- Correctly scope the work: Taking on too much work is a recipe for disaster. Teams can mitigate this challenge by anecdotally looking at their velocity and establishing a more reasonable scope and cost estimates for the work. Doing so reduces the potential for delivery failure.
- Ensure the right skillsets: Prior to making a commitment, teams should determine if they have the right skills to build the requested capabilities.
- Root out duplicate work. Few software experiences are as frustrating and costly as spending time on important ideas only to discover that, down the hall or across the globe, someone else in the organization has been innovating on the same ideas.
To prevent redundant efforts, software development organizations can create a community to share ideas and knowledge, solicit feedback and potentially pool resources to move at a more rapid pace. This can be done in both low-tech ways (newsletters, town halls, brown-bag events) and through social media. In order to establish a strong community, it’s also vital to identify obstacles to this lack of communication and overcome them.
- Automate. Talk of automation often stokes fears of complex reorganizations, high implementation costs and job displacement. However, the process of offloading rote work to machines actually offers opportunity to software teams: It’s an opening to become better at their jobs. When machines contribute to equal or improved outcomes, they clear a path for fast progress.
For example, insurance companies are automating the onboarding process for clients, streamlining repetitive tasks and using technology to provide a more personal experience. Financial services companies, meanwhile, are enabling faster credit checks through automation, streamlining the purchasing process for big-ticket items. In most cases, automation means letting machines do what they do best (i.e., fast processing of rote tasks) and enabling humans to do what they do best (i.e., empathy, creativity, judgment calls). (For more on this topic, see our recently published book What to Do When Machines Do Everything.)
- Learn to fail fast. There’s a reason the concept of failing fast has become ubiquitous in business: It works. The rhythm of releasing a minimally viable product (MVP) , getting feedback and then making changes forces software teams out of the rut of analysis-paralysis. Failing fast, however, isn’t the same as falling short of revenue requirements, quarter over quarter, and watching market share decline. The proper way to fail involves testing assumptions, finding out what doesn’t work and building software that solves real needs.
For many software development organizations, the hardest part of innovation is carving out time for it and building it into their day-to-day processes. By taking a series of small steps, however, organizations can quickly establish an innovation discipline that ensures relevance far into the future.