The words “innovation” and “scale” are at direct conflict with one another. Innovation is messy, it’s inefficient. In contrast, “scale” requires efficiency.
For example, think of McDonald’s vs your local burger joint. McDonald’s pumps out millions upon millions of identical burgers, and sells them fast and cheap. In contrast, your local burger joint might experiment with different recipes each week and might buy produce from various local vendors. If McDonald’s did that, they’d fail. Yes, they do experiment, but it’s controlled experimentation.
Yet, despite the inherent dichotomy that exists, innovation is possible at scale. The key to effective innovation at scale is to take the time upfront to define the guardrails of success and failure, and to pull a few best practices from startups:
Step 1: Define success and failure
Treat innovation inside enterprise teams like a real startup. Explicitly define both success and failure before you begin the innovation. If you aim to release a new product by June 31st, then success might be 5000 users by September 1st. Go a step further and define Red, Yellow and Green outcomes:
- Red - fewer than 1,000 users
- Yellow - 1001-5000 users
- Green - 5001+ users
Once you have Red, Yellow and Green defined, explicitly state what happens if you hit Red, Yellow and Green. For example:
- Red - no bonus payouts, the team goes from 4 people down to 2, and gets another 3 months to hit target or the team folds up
- Yellow - $10k bonus per team member, the team stays at 4 people, and the team then defines red, yellow and green targets for the next 6 months
- Green - $30k bonus per team member, the team stays at 4 people, defines targets for next 6 months
Step 2: Make the risk of failure real
Both compensation and job security need to be on the line. Way too often, enterprise teams do not implement any repercussions for innovation teams. That is a huge mistake. To innovate, there must be a true risk of failure. For example, in our scenarios above, you could say that if the team hits Red, in addition to the outcomes listed above, the team members are rolled off onto other projects. In some cases, I’ve seen people get salary cuts, demotions and even fired for failing to achieve innovative objectives inside enterprise teams.
Step 3: Give upside
The flipside of step 2 is that the success should be real too. Give the employees upside, just like in a real startup. For example, a tech lead making $130k/year moves to the innovation team and their compensation becomes a salary of $100k/year, and a bonus potential of up to $40k if the team hits Yellow and a bonus potential of $70k if the team hits Green targets throughout the year. If things work out, she’s making more than she would have, and if things don’t work out, she’s making less. Bonus targets ideally are tied to team performance and not individual performance.
It’s interesting to me why more established companies don’t provide real upside when they form innovation hubs. Startups often give equity, options, bonuses. Yet for some reason, big organizations form an innovation hub team and keep their compensation aligned with the rest of the organization. In my opinion, teams working on innovation inside startups should be paid as if they were working at a startup, which equates to lower guaranteed pay and the change at a big upside.
Step 4: Learn from Failure and Embrace Change
At big companies, individuals often fear failure. At startups, failure is expected. Big companies need to take a lesson from startups here. Embrace failure by:
- Holding retrospectives frequently, to ensure the team bubbles failures to the top and learns from them. Learn how to facilitate an Agile retrospective here.
- Work in 1-2 week sprints. This way, failure is quick and any adjustments can be made frequently.
- Create a culture that embraces change by rewarding those that ask questions and admit to failure. At Stride, we have quarterly Stridees, and we literally give out awards for the individuals that displayed the best Learn from Failure value.
Step 5: Run the entire organization using Agile
If the executive team uses an annual cadence with lengthy signoffs, real innovation will be next to impossible. Instead, use 2 week sprints and iterate on everything. I'm not talking about the tech team here, I'm talking about running the executive team this way. At Stride, our executive team has 1 week sprints. We meet Tuesdays 8:30-10am, and each week prioritize and debate the highest priority issues and leave the meeting with action items with 1 owner and a due date. We also have quarterly strategy planning sessions that last 2 days, to ensure we are continuously iterating on the most strategic elements of the business.
Want to learn new tactics to help you be a more effective developer? Check out our Tips all Developers Should Know to help you advance your career.