In plain financial terms, departments are viewed as either profit centers or cost centers. The former generate revenues, while the latter only do so indirectly. Sales and marketing are typical examples of profit centers. R&D and engineering are often counted as cost centers. My premise is that by accepting this viewpoint, you will be losing out on substantial gains. In this chapter, you will learn how to make innovation an integral part of your organization. Doing so will unlock business opportunities, market-leading edges, and, ultimately, profits.
Cost Center?
Maybe you never gave this distinction any thought, or perhaps you have taken it at face value. If you’re wondering whether it is that bad, let’s start by understanding how this can handicap your team.
Cost centers are expected to operate at, or below, budget. The budget is often set by taking into account the work that the team is expected to perform, and that’s it. Moreover, in some kinds of businesses, budgets are first allocated to the profit centers. Whatever is left then determines what will be expected of the cost centers to perform with the remaining budget.
When the R&D budget is deduced from a given feature roadmap, it is cut precisely for that. Rarely do you retain enough wiggle room to allow for surprises, experimentation, novelty, or innovation in general. This leads to a vicious cycle. The team does not have enough resources to do anything except for the tasks it was given, no extra value is generated, and it performs as expected: as a cost center. When it comes time to allocate budgets again and there is no past experience suggesting otherwise, the same process will be done.
Operating in a way that is this tightly coupled with the product roadmap doesn’t leave a lot of room for anything else. Whether you like it or not, you will align your team to achieve those goals and those alone. The expectations will be of delivery, and a good team will live up to those expectations. This betrays an essential chunk of the impact that could be achieved.
Frankly, this way of thinking is one of the biggest wastes I see in our industry. I can’t help but cringe when I think of all the wasted potential. We are taking a whole slew of extremely bright and talented people and pay them a fortune accordingly. All that to pigeonhole them to comply with a given roadmap and to focus on rote delivery. That’s a costly mistake to make.
The Innovation Vision
There are kinds of R&D investments that you can relate to surely. Apple shows advancements in sensors, processing, materials, and algorithms every year. These don’t just spontaneously happen. Behind the scenes, extensive efforts are being made. A swath of experiments take place, with many failing, before progress is achieved. That’s the price of innovation. To take the lead and bring something novel to the world, you will need to put in the effort, the investment, and the time. But it is worth it.
First, you get to enjoy the fruits of your novel ideas. Apple is leading the market in many aspects, precisely due to those. When creativity complements your existing offerings and product direction, it acts as a catalyst for sales, adoption, and more.
More than providing you an edge in the market right now, regular innovation is also the only way to create a long-lasting business. The reason “enterprise software” is whispered with slight terror in most startups is because they fear becoming a slow-moving giant. That inherent tardiness includes a lack of innovation. When you stop reinventing, challenging the status quo, and moving forward, you will eventually atrophy. Lacking the ability to innovate regularly will result in an utter failure when a market-changing moment arrives—you cannot grow an innovative culture on demand after letting all your creative muscles shrivel away.
Successful innovation will allow your company to “skate to where the puck is going to be” rather than where it currently is. This ingenuity works wonders for everyone involved in your organization. Evidently, people enjoy being part of an innovative and creative team. That is how a culture of innovation adds many intangible benefits, such as better employee retention, improved morale, and increased motivation.
Lastly, to be able to innovate, the team has to obtain remarkable product mastery. In Chapter 2, we covered your executive product mastery, and Chapter 10 focuses on product mastery for your employees. Since product mastery is a prerequisite for valuable innovation, you get two for the price of one.
Types of Innovation
No one will say Apple should be stopping creative endeavors and experiments to focus solely on delivery and marketing. It is a vital part of their edge in the market. Not all companies require this kind of trailblazing to succeed. But every business can benefit from the right amount and the right types of innovation. Let us consider the major types. At least one will likely apply to your company.
Product Novelty
This type of innovation consists of new ways of doing things or new kinds of offerings. Often, it does not require inventing anything groundbreaking. Instead, it is about connecting existing solutions together or enabling things that were not possible before.
For example, think of something as simple as a meditation app, a piece of software that mostly consists of playing back recorded sound clips and counting time. Yet there was enough novelty in enabling this for consumers that there are several unicorns in this space.
Another well-known example would be Intuit. They provide a whole slew of products for financial needs, like payroll and taxes. Again, at the core, these products consist of straightforward operations that are codified in a way that nonprofessionals can use.
A standard class of these kinds of apps falls under the name “CRUD applications.” Those are mainly database applications that create value by digitizing processes.
Technological Edge
This type consists of profound technical advantages that frequently stem from significant investments in innovation. The earlier examples of Apple’s innovations in screens, materials, sensors, and so on are great examples. Nevertheless, not all technological edge is about hardware.
Think about the team that has created a world-leading machine learning model that is more accurate than anything else on the market. Another example would be a cyber startup with renowned security researchers who repeatedly find zero days and capabilities to retain their edge. One last example of this innovation type would be the life-saving startup that can analyze medical test results to find issues before human doctors can. All of these are based on innovative approaches that are not easily copied elsewhere.
Tech Capital
Tech debt is something that engineering teams tend to discuss regularly. Picture what you would do if you had a friend who repeatedly talked about debt, loans, and maxing credit cards. Most code and features end up becoming a liability—another thing to keep refreshed and maintained as time goes on.
Tech capital is about those endeavors that form assets that keep accruing in value with time. Think about the creation of tools that empower and enable new capabilities internally. This isn’t any single feature, rather the ability to create a series of related features or allowing counterparts in the company to do things that were impossible prior.
The regular creation of tech capital is magical, where every new piece of it acts like another force multiplier working in your favor. The most basic example would be internal tooling that saves engineers’ time and reduces mistakes in error-prone processes. Another everyday use case is the creation of tools for other departments, like a data collection tool that helps salespeople reach deeper insights and target the right prospects or an internal CMS that allows people in marketing to change emails without having to wait for engineering’s time.
To use a well-known example, think of Basecamp’s Ruby on Rails framework. It started off as an internal tool that allowed the company to deliver features at breakneck speed, iterate rapidly, and grow quickly. It is an asset that enables incredible, superpower-like progress to be made at times—and it is so valuable it is used by other developers worldwide.
Process Ingenuity
One last type of innovation is about finding better ways of doing things. Whenever you release a new feature, your competitors can check it out and often copy it relatively fast. If, however, you change the process by which you create value, then it will be much harder to copy.
Processes are tightly coupled to culture, which is why changing them is hard (and why discussing change management is so important; see Chapter 7). Copying them from one company to the other, especially without guidance, can sometimes be impossible.
The company that works with agile methodologies will always beat a big-design-upfront competitor. Organizations that are working in a cross-functional way and have autonomous teams are likely to drive more impact than others. Even the way that you handle production outages or the personal growth of your people can be seen as processes that provide you with an edge. Process ingenuity helps you create and maintain a better product, but it won’t always affect the product itself directly.
Which Fits Your Needs?
Your company does need to be world-class at all of these types of innovation. For your organization and the market that you operate in, consider which of these is best to invest in. You should not try to spin up multiple of these unless you already have a substantial lead in one, as it will make your team feel like a glob of butter scraped over too much bread.
Do you already have an advantage in one area?
Is there a type that none of your competitors excel at?
In large enough R&D organizations, it can make sense to have different groups focus on different innovation types.
Does any of these kinds of innovation compliment the grander parts of your company’s vision or uncharted areas of the product roadmap?
After you decide which is the most important to you right now, start innovating.
Implementing Innovation
Unless we are talking about research teams, it is not like anyone on your team will have a Jira task that says “Innovate” with a deadline for the end of the sprint. The onus is on you and your management team to establish a culture where innovation is a regular occurrence. You need to provide the appropriate conditions for it to take place.
While the right set of steps you should take will need to be tailored for your team, there are some that frequently help. These are the ones I've found to show the best results empirically.
Get Some Wiggle Room
Thinking back to the problem of sizing your group precisely to the measures of the declared roadmap, you want to add some buffers. Many tech executives treat the budget numbers that are initially discussed as set in stone. It is up to you to speak up and make a case for hiring extra people to account for experimentation.
If your teams know they cannot tolerate any failure because you’ve allocated every single minute of every single sprint this year, then they won’t innovate at all. Once you have in mind the types of innovation that you’d like to see more of, help your colleagues see the benefits and the potential upside from such an investment. That is the only way to secure a bigger budget that will allow it.
A concept that I find helpful is to discuss those investments that fit Nassim Taleb’s barbell strategy. While about 90% of your efforts should be dependable and relatively low risk, you should invest in some efforts where the risk is capped (i.e., you waste a specified amount of time on development), but the reward is virtually unlimited. Then, staff up to allow for this to happen without risking your product roadmap.
Make It a Part of the Job
For your team to believe that innovating is valued and vital for the company, you have to put your money where your mouth is. You should make the time for them to try things out, tinker, and work on non-feature work.
Non-feature Work
Non-feature work comprises tasks that are not defined by the product team. It includes tech debt, bug fixes, maintenance work, and, most importantly, tech capital. Things like bug fixes should be prioritized by product, and it can be hard for them to determine the value of tech debt and tech capital.
What many organizations try to do to strike a balance is to decide on a fixed portion of their time to be allocated to tech debt. It’s prevalent to have a proportion of 20–30% of an engineering organization’s time to be set for internal needs. I have qualms with this pattern. First, it is often an organizational “smell”—it is created to avoid friction between engineering and product. As mentioned in previous chapters, the engineering-product partnership is the most important one for you and therefore should not be worked around. Second, this fixed allocation often results in wasted efforts. Sometimes tech debt tasks of very low impact are done to fill up the time. It also prevents any big leaps in technical investment as the team is forced to work in these 20–30% increments.
Intermissions
Innovation is not likely to prosper in such a constrained way of work, which is why I recommend a wholly different approach: intermissions. Intermissions are regularly scheduled blocks of time where the team has full autonomy to decide what to spend them on. Many successful companies use these or similar concepts, such as Basecamp’s sabbaticals. It boils down to creating a schedule so that teams have 3–5 days of intermissions between every one or two sprints.
There are a few significant advantages to investing time in intermissions regularly. First, just the act of having some extra time between the end of one sprint and the start of the next can result in a more impactful sprint. When sprints are always back-to-back, the product team has to “feed the beast” and provide the developers with tasks without having time to see the results of the last sprint in action. A sabbatical allows for new features to be used in production and responding to what the team learns faster.
A second advantage is that it helps focus the team during sprints. When there’s a sprint, everyone is involved in achieving its objective. When in an intermission, everyone is trying out things together. I prefer this to the more common pattern where a couple of engineers tend to get the majority of tech debt and platform tasks while the rest focus on feature work.
Yet another upside is that it helps with motivation and makes your people be more proactive and take initiatives. That’s because they see that they have the ability to determine what they do, at least in part of their time, and the best engineers I work with are always eager to maximize these periods.
Cascading Intermissions Between Sprints
What Do You Do on Intermissions?
One thing that is essential to realize about intermissions is that they are not “free time.” The concept might remind you of Google’s 20% time, where people are allowed to work on whatever project they want. Ideally, your teams should have internal backlogs and decide on how to use the intermissions best. I know that these have been wholly ingrained in a company’s culture where every engineer maintains a private backlog in a file and comes equipped with it to the intermission kickoff meeting. That’s a great example of autonomy and initiative by developers.
Some of the work can be tackling tech debt, like upgrading an old package you depend on. Some of it can be used for learning and trying things out. For example, one team might decide to create a prototype of a new service using new technology they’re not currently using to assess better whether it will be a worthwhile addition to their arsenal.
A considerable portion of intermissions, though, should be invested in innovation, trying out things that have the potential to pay off well. Think of it as managing an angel investing portfolio. Most of the things you do will not end up being tremendous game-changers. Nevertheless, having even 10% of those become wildly successful will help your team amass a vast armament of force multipliers with time.
Google’s 20% time has brought the company many wildly successful achievements, like Gmail or Google News, and other companies, like Atlassian, agree. The significant difference between that approach and intermissions is that we aim to make this a team effort that gets progress in bursts. That is as opposed to 20% time that every individual allocates differently. When progress is only gained in single-day steps and people can rarely work together, you lose out on a lot of the benefits of brainstorming, working collaboratively, and fruitful debate.
One of the brightest VPs I was working with knew that his group was not spending enough time on big-bet innovations. Their heads were filled to the brim with new ideas and approaches, but they were entirely focused on routine work, never making the time to get it done. After all, no one wanted a team to come up after a sprint or two saying that they had nothing to show for it. That was a waste, as a bunch of incredibly talented engineers was not fulfilling their potential.
Together, we implemented some of the tactics described in this chapter, like getting wiggle room, setting innovation as a value, and making it part of the work. He articulated the barbell strategy that he was taking and got approval from the rest of the executive team to change the roadmap accordingly.
Two intermissions later, one of his teams unlocked what they called a “bonanza”—a capability that will allow them to create a wide moat that will differentiate them from the competition, likely for several years. The intermission showed a successful proof of concept, and the product roadmap was altered again to account for the new possibilities this introduced. To this day, they are still unchallenged in this space.
Kicking Off Intermissions
Introducing intermissions to your time is a change initiative, as covered in Chapter 7. I recommend choosing a few champions who are likely to have a personal backlog of ideas (whether written down or solely in their heads). Having a few key motivated people who are already chomping at the bit and eager to start can be contagious.
Make it clear to everyone that the time is theirs to decide how to manage it. Your champions are likely to get some people involved in their ideas to work on them together. Others can try out small changes and improvements.
I highly recommend leaving product out of these blocks of time—your people should find something worthwhile to do on their own or, if necessary, with some guidance from their managers. Only if someone has wholly exhausted other options should you let them, for example, pick up a bug from product’s list. Note that bugs the team cares about are completely fine to address. A common example of bugs that product wouldn’t care about for low user impact but that your group would like to see resolved are bugs that make data “dirty” or spam their logs. Those are valuable to solve in an intermission if the team thinks so.
Account for Innovation
Another aspect of making innovation part of the work is to make it everyone’s job. It should be something that is brought up in one-on-ones and performance reviews. If you create a career ladder for both individual contributors and managers, make sure that it contains an assessment for innovation, creativity, novelty, and other such initiatives. Otherwise, speaking about innovation will merely be a dead letter.
Measuring innovation as part of an organization is detailed at more length a bit later. However, for individuals, it has to be done more loosely. Start by counting how many ideas they’ve brought up when kicking off intermissions. If you’re wondering whether you should measure their successful ideas, not just all ideas, then move along to the next session.
Failing Spectacularly
You’ve heard a hundred stories where a field was disrupted not by a subject matter expert but by someone who was a relative newcomer. Part of it is due to the fresh perspective that newcomers have. The other part is that the more entrenched we are in a specific field, the more likely we are to grow an ego that we coddle. One becomes afraid of making mistakes and, in turn, less likely to try something new that might not work.
Add to that the apparent refrain from missing deadlines or being wrong in a work environment. It can take some effort to cure what hundreds of sprints have ingrained in people. The first step toward that is to embrace failure. You and your lieutenants should be extremely clear about the “angel investing” mindset: most of what you try will not become bonanzas. As long as enough do to get a positive ROI, that’s alright.
For this to stick, there should be psychological safety when it comes to failing or trying out things that don’t work. As with many other cases of cultural changes, for many people, seeing is believing. As you kick off the first few intermissions, many might still be sticking to relatively low-risk (and likely low-reward) endeavors. Your champions, though, should be starting with more challenging stuff. As we know, a lot of those will not have an amazing result. That is the point where you and your management team will be required to walk the walk.
We’ve already discussed the importance of celebrating wins in previous chapters, but now comes the time where you should celebrate taking the right kinds of risks. I wouldn’t celebrate someone failing to use a bleeding-edge tool with 1.5 maintainers just for the coolness factor. On the other hand, trying to use a new library that could’ve saved costs but turned out to be still immature? Sounds well worth the shot.
Celebrating failures might seem weird, but that is how you encourage taking the right kinds of risks and moonshots. Some companies are known for handing out prizes not just to the best innovations that worked but also for the craziest idea that failed. Give you and your team a license to make a leap of faith and try something that might not work. Anything else, and you’ll be capping your likely innovation.
Hackathons are a Hack
One last point about implementing innovation in your organization is about avoiding hackathons for this. Hackathons provide a welcome breath of fresh air for organizations that rarely spend time doing anything new or innovative, and therein lies the rub. Hackathons are a good idea for teams that are starved: it’s better than nothing at all.
The problem with the once-every-quarter (or longer) hackathon is that it teaches people to quench all their ideas and wait for the “allowed innovation time.” You end up creating creativity black holes, where people learn that they’re not supposed to be letting their ideas come out till permission is granted. Putting innovation silos in place is counterproductive. Don’t get me wrong; you can have regular hackathons happening to get the benefit of the entire team (or even company) working together as opposed to the smaller scale of intermissions. But these should not replace ongoing, more frequent intermissions to allow for constant tinkering and improvement.
Making Smart People Think
Implementing innovation is by itself a good start, but might not be enough for great results. If your team merely goes through the motions without the ability to be creative and try new things out, they are not likely to accomplish significant breakthroughs, no matter how much they try.
This section covers the different ways of encouraging a culture with enough trust to unlock bold ideas and prosper.
Invest in Learning
The first part of unlocking creativity is that the team has to possess mastery of its tools, environments, languages, and frameworks. You know the saying that to a person that only has a hammer, all problems look like nails. Engineers rarely have only a single tool. Nowadays, they have a truckload of tools at their fingertips, but they are likely to have only mastered a handful. That’s why sometimes they might go off reinventing the wheel—they don’t know they have the perfect one already lying at the bottom of their toolbox.
Most learning inevitably happens as part of the job, which is a good thing. You can still induce accelerated learning throughout your team with a few adjustments.
Learning Budgets
Every person’s optimal learning is achieved differently. Some people get a lot from conferences and hands-on workshops. Others like online courses. I mostly prefer a great book, along with a small project. To each their own. That goes to say that rather than trying to control all the learning that takes place in the organization, you should allow for autonomy here whenever possible.
One typical example is to allow for personal learning budgets. Each person gets a yearly budget to spend how they see fit. Encourage your team to invest in their own learning to continue broadening their horizons and get better acquainted with their tools.
Be Old-School: Dig One Level Deeper
I wrote a wildly popular blog post in 2011 lamenting the fact that many engineers have stopped understanding how their tools worked. A decade later, it is more relevant than ever. I call it “being old-school,” as a couple of decades ago, engineers couldn’t rely on Stack Overflow and the likes to solve everything for them.
Don’t read this as someone yelling “Get off my lawn!” at youngsters. This is about ensuring that with time the team as a whole understands the underlying mechanisms of its tech stack to be able to solve issues faster or avoid them altogether.
I cannot tell you how many times I’ve helped debug issues others took hours to solve by understanding how TCP/IP works and being able to pinpoint the cause faster. How many web developers don’t know how HTTP cookies or CORS work, so once they have bugs, they lose days on end trying to find the right blog post to save them? My favorite of all is whipping out git bisect to find the cause of a bug in minutes—it always looks like sorcery to people who have never heard of it. We have a saying: no matter the time of day, if you’ve used git bisect to find a bug, you can call it a day.
Whenever your post-mortems spot these kinds of blind spots in your organizational knowledge, make it a point to address it. I love having someone research the topic and then share it internally in a tech talk. A team that learns together grows together.
Tinker Away
All work and no play makes your people miss out on loads of learning opportunities. It is incredible the amount of creativity and learning we can accomplish just because we want to make something seemingly stupid happen. However, tinkering and playing are how we learn a lot and practice our creativity muscles.
In The Creativity Leap , creativity strategist and my friend Natalie Nixon describes the importance of integrating regular play into the day-to-day work to accelerate learning and help creativity prosper. After all, a lot of innovation is connecting old ideas in a way that was not done before. That’s harder to come by if you don’t know a lot of ideas to start with.
I know that I dismissed hackathons a bit earlier, but they are great precisely for these kinds of purposes: trying out new things in a fun and stress-free environment. It might seem odd to let people learn how to create Slack bots so that they create one that helps arrange basketball meetups after work. Nevertheless, you’d be surprised how many of these end up evolving into practical tools when suddenly you have members who can think of such integrations as straightforward.
In my army service, we had a habit of finding geeky ways to prank one another (to my defense, we were 18–20-year-olds). In hindsight, those ended up contributing to our daily work. There was this one time where my team visited a server room in a base to do some maintenance but realized that the servers had no identification stickers on them and the paper mapping out their layout was lost. We thought we were going to spend hours trying to untangle wires to find out which is which. Then I had an idea: I connected remotely to servers and ejected the CD tray to see where it was physically. We were done in minutes. Where did I get the idea from? I learned how to mess with CD trays just so I could randomly open them on our workstations, poking my teammates’ knees.
Another prank involved learning how to transplant an icon on someone’s screen remotely. Keep in mind this was before screen sharing and remote control were easily doable. The knowledge of doing this was later used to support users of our systems remotely: we could draw arrows pointing at what they needed to click as we were helping them on the phone.
Tinkering helps you dig deeper and better understand our tools. That way, when the need arises, you can think of ideas much faster and are already aware of various possibilities. You are practicing to make it easier when it’s game time.
Cross-Fertilization
When it comes to creativity, every single person added to the conversation brings another fresh set of eyes and a different perspective for looking at the problem. That addition might just be what was missing to make a leap forward. You can design your work processes to allow for more cross-fertilization to take place and break silos. This is especially important as teams tend to think more and more alike with time. By regularly working with people from across the organization, you prevent idea degeneration.
First, start by ensuring that technical mentoring and consulting are not compartmentalized between teams. The most obvious example would be regular code reviews and pull requests. In a cross-functional organization, there are engineers in other teams with the technical capability to assess the work—even if they are not masters of the specific system that is being changed. They can weigh in about clarity, conventions, ideas for libraries that can save work, and so forth. Having several people review work and not all of them from the same team brings in more ideas and helps with collaboration and spreading work habits and norms across the organization.
This can also be applied to other ongoing work, like design reviews, brainstorming, and more. There is no reason to be limited to a specific team or group. The biggest obstacle to this healthy collaboration is often that engineers don’t want to “waste” time on tasks that belong to other teams (or their managers don’t want them to). One of the guiding principles in every R&D group should be mutual assistance. If you notice that you are experiencing an issue here, bring up its importance to your managers and find a balance that works.
Another way to achieve cross-fertilization is to make sharing knowledge routine. I love seeing teams do regular tech talks internally (e.g., about what they learned in an intermission). Not only does this help spread knowledge throughout the team, but it is also conducive to the growth of your individual contributors and improves communication. Similarly, you can make a habit of putting people “on loan”: every engineer can pick a sprint (say every 6 or 12 months) to join a different team. While they might not be able to be as productive or independent there, everyone gains a better understanding of what is happening around them.
Avoid Groupthink
A great way to hinder innovation is to go into a brainstorming session with many people unprepared. What ends up happening most of the time is that one or two relatively senior or valued engineers speak up and the rest tend to align with them—no one wants to risk sounding stupid or going against others. Think about the different practices of “planning poker” from agile methodologies: each person involved is asked to write an estimate, and only after doing that everyone shares. Otherwise, once Emma has said she thinks something will require two days, no one will want to voice concerns and say a week is what they had in mind.
Similarly, when you really want to collect different ideas and perspectives about an important problem, start by collecting ideas individually or in small groups. Once you have a bunch of different approaches, making them part of the agenda of a brainstorming session is a lot easier. That’s a surefire way to create healthier discussions and collect more ideas.
Hire Heterogeneously
Isn’t it great to hire someone whom others in the team have worked with in the past so that you have a recommendation that you can trust? It seems to reduce friction, you have better “culture fit,” and things are just easier (not to mention the benefit of referrals from employees: you don’t need to pay external recruiting fees).
I often come across companies that hire most of their team from a specific “pocket.” Everyone is alumni of the same university, used to work together at a tech giant, and so on. This speeds up hiring and makes the team gel faster, but at the cost of losing out on a larger variety of backgrounds, perspectives, and approaches.
The most creative groups I’ve worked with were those that had minimal use of such pockets. Every person was a multiplier of creativity and innovation. Make sure not to get addicted to easy hiring at the cost of creating a too homogeneous team.
And as you do your best to kick off innovation and make everyone think, it is good to create a yardstick to help you tell whether or not your efforts are paying off.
Measuring Innovation
Going through these lengths to encourage and induce innovation is a significant investment. As with every such step, you want to make sure that you get a positive return. Innovation, though, is not straightforward to account for, especially when you are not managing a group that is entirely dedicated to innovation and research.
Ideas deployed: The most straightforward indicator would be to keep count of the number of initiatives and ideas that originated from your team and ended up being deployed and positively impacting your users or the business. Did the push for a mobile app increase engagement? Had you improved the loading times of your website and saw an uptick in sales? Depending on the kind of business you are in, assessing the ROI of those improvements over 6–24 months can be a good indicator.
Internal acceleration: Innovation does not always directly affect the bottom line. For example, tech capital efforts can result in new internal tools. Similarly, process novelty might translate into faster cycle times or improved quality. These are so invaluable that I look for them when starting with a new client to get a quick grasp of their innovation. Measuring the leaps forward these internal tools achieve is another great indicator, by looking at the time, quality, and similar.
Product regeneration: Company-wide innovation can sometimes be measured by tracking the percentage of revenue that is being driven by new products or features in a 12–24-month period. This is a great way to ensure that you are not letting the product become stale and allow the competition to leapfrog your offering.
Capability: Lastly, if none of the previous work for you, you can get a feel for how good you are doing by tracking your group’s ability to accommodate the company’s roadmaps, goals, and new initiatives on time and budget. Without innovation, these abilities don’t tend to hold up over time.
Using any one of these or even an adjusted metric that you come up with is a great way to keep an eye on your innovation efforts.
Your Personal Upgrade
Leading a team of motivated professionals is incredible. Helping such a group be a driver of growth and creativity is likely our profession’s pinnacle. Shifting your organization from a cost center to an innovation center takes time, money, and effort. However, without doing it, you will be wasting potential, missing out on business opportunities, and, frankly, losing out on a whole bunch of fun.
Making the switch starts with your own perception of your team. Once you believe the leaps you all can provide, you will be able to convince everyone else. You might need to adjust your organization, such as hiring more or mixing things up. The next chapter is all about that.