Over the past six years, Cedar has grown from a scrappy startup to a mature company with more than 55 payer and provider clients, engaging with more than 400,000 daily consumers on average. Early on, we fostered a culture of innovation as we designed and built our flagship product, Cedar Pay.
In short, we’re no longer a small startup–but we still need to innovate like one. So we’ve created teams focused on innovation that can operate with the agility of a startup while benefiting from the resources of the larger company around it. This has helped us:
- Build novel features on Cedar Pay, like consumer experiences that combine health plan data with patient billing
- Make major enhancements to Cedar Pay as we work with new types of healthcare providers
- Design and launch new products from the ground up like Cedar Pre
Technologists and business leaders too often believe that the above model “just works,” that is to say automatically. It absolutely can–but it takes deliberate effort and lessons learned from experience.
We’ve worked at companies ranging in size from five to over one hundred thousand employees, so we’ve seen a lot of different approaches to product and engineering innovation. We compiled a cheat sheet that will hopefully serve you well when you find yourself (lucky you) with the need to spin up an innovation team!
Don’t spread your team too thin
One of the most common pitfalls is assuming ambitious projects can be tackled by very small teams.
Working in a medium or large company is never the same as working in a startup. In a startup, it is often possible to get into a flow state for most of the day and focus on one problem. That’s really challenging in a larger company. Sure, you can try to completely silo the team off from the larger company, but that will foster feelings of isolation.
Also, leaders who haven’t worked in a startup tend to underestimate the effort required to do something as challenging as building and launching new products. Carefully consider the effort and time needed for discovery, iteration, feedback, brainstorming and scrambling.
The takeaway? Make sure to resource accordingly, start slowly and build from there.
Find people comfortable with unknowns
Many product managers, UX designers, tech leads, and engineers aren’t accustomed to dealing with a high degree of ambiguity; they want a predictable linear roadmap from A to Z.
These teammates are excellent executors and can be key to successful mature products, but they may struggle on an innovation team. So properly set expectations and staff the team with teammates who are comfortable in situations where “the script hasn’t been written yet.”
Leverage your existing tech stack
To avert the risk of mixing production and experimental code, teams will often build from the ground up. This “reinvent the wheel” approach results in new and extraneous code frameworks, logic, interfaces, hosting infrastructures and tooling. New processes for devops and on-call support may even be stood up. All of this distracts from execution.
In addition, if your new project is successful, how will you integrate this into the existing stack? Do you drop it on the rest of the company and leave others to figure out integration and maintenance? If the coding language or core frameworks are different, you’ve created a huge training burden. And if there’s substantial logic overlap, you’ve created a major (and avoidable) refactoring effort.
Focus on re-using as much of the existing stack, tooling, coding languages, and devops processes as possible. While it’s important to minimize risk to production, you can do so with many simpler, tactical approaches (i.e. use a separate database to power your new feature).
Set the right level of code standards
Do NOT throw out all coding standards to gain speed. Practices like code review, automated testing and clean separation of responsibility are necessary to maintain even short-term code quality. Abandon these practices at your peril; your team will quickly find itself dealing with bugs and knowledge gaps that distract from rapid iteration.
Holding new code to the same standard as existing production code is also inadvisable. Mature product features are typically built with the expectation that they’ll be maintained by different engineers for the long haul. Technical designs will (and should) be scrutinized for extreme clarity, code will be reviewed for performance at scale, and there will be expectations for reporting and production incident handling. Train your team (and their code reviewers) on what is still important versus what is less important for new product code, or you may well lose velocity and waste effort when a pivot is needed.
Create a destination
How often have you traveled without an intended destination? It may sound exciting and romantic, but as a career it would quickly feel arbitrary, aimless and devoid of meaning. We need a destination to get on the “daily train,” even if we don’t know all the stops along the way.
Creating a new product entails bumps in the road and unexpected stops, but the destination should never be in doubt. Your team needs to know where they are trying to go and the benefits of each step. Clearly, consistently and frequently communicating and documenting the goal is essential to ensure all team members’ buy-in and alignment on the journey.
Bring structure to your team
Being inventive requires ambiguity and flexibility, but it isn’t necessarily structureless. When possible, incorporate structure to ease the unsettling nature of the unknown, for example:
- Adopt a routine development methodology
- Create living product and technical roadmaps that serve as a flexible destination guide
- Establish progress and customer benefit metrics
- Document timelines and explicit milestones
These may seem normal for an innovation team, but you may be surprised at how many teams don’t have these kinds of basic structures in place.
Enforce and encourage community
Consider your career and think of a position or company that you truly enjoyed working for. What stands out most? It’s probably not money or benefits; those are short-term motivators that don’t leave lasting impressions. You more likely reflect on community: individuals who became friends and family.
In an innovation team this is even more important. Team members can feel excluded from the larger organization because they work on projects “unrelated” to core products or on issues outside of current concerns. This type of work can easily lead to feelings of isolation and separation, leading to poor morale, performance and a high turnover rate. So what to do?
- Keep your team involved in company traditions like celebrations and meetings
- Create mentorship opportunities outside the team
- Source ideas and feedback from outside team members
There are so many things you can do to create a productive and innovative community, but you can’t do it in a silo. A team needs a community of hearts and minds to help along the way.
Embrace the iterative method
When developing something new and inventive it’s going to take learning on how not to do it before you determine the best way to do it. Engineers are notorious for being perfectionists, so imparting this wisdom to a team of highly skilled and innovative individuals can be difficult. That said, there are are a couple of best practices:
- Set up recurring meetings to talk strictly about lessons learned. Embrace conversations about what didn’t work and thoughts about moving forward
- Document things that don’t work in addition to those that do. Engineers enjoy seeing the fruits of their labor, but when it comes to innovation it’s easy to focus on “failure.” Acknowledge what didn’t work, then focus on lessons learned, and what to do next!
