Big technology companies empower their developers to explore, tinker, and innovate on company time. For example, Google encourages employees to spend up to 20 percent of their time on side projects. This exploration doesn’t have to focus on the company’s existing products; engineers are also allowed to experiment in tangential areas of interest. Allegedly, Gmail, Google Maps, Twitter, Slack, and Groupon were all born as side projects. That’s a phenomenal return on investment born from a culture that fosters experimentation.
Does Exploration in Small, Early Stage Startups Distract From Core Value Creation?
This is all well and good for a tech giant like Google that can afford to give engineers a break from core development from time to time. What about small technology companies though? Founders or CEOs of small or early stage startups have to guard precious resources. Those companies are frequently cash strapped, and everyone plays multiple roles, including washing dishes in makeshift kitchens. I may be speaking from experience here, but this kind of chore isn’t unusual at small startups!
Any activity that takes someone away from core value creation is terrifying to a founder. If engineers are distracted from product development, creating deliverables and meeting deadlines, how can they deliver your product to customers? The exigencies of growth also make it vital to get a quality product to those early customers. These customers can validate your market, become references, and help the company scale up and out. This process is critical to securing additional investment, so it feels imperative to focus only on your core product to create value.
In reality, this narrow view is a double-edged sword. Your team does need to be hyper-focused on your product so you can drive revenue and grow in order to obtain more resources. Once you start growing, then you’ll have more space for the kind of exploration that the big companies foster so openly. But the early stage is also when you most need to encourage innovative engineering so you can gain a competitive edge and ensure your road map won’t become blinkered.
It’s counterintuitive, but even the smallest, most bootstrapped software companies need to give their engineering teams the freedom to experiment. I learned this lesson with my last company. If my team hadn’t felt safe to experiment — and come to me with their findings — we may have stuck with the wrong product roadmap.
For teams to feel safe enough to experiment and share their findings, they need to have what organizational psychologists call “psychological safety.” Google’s now-famous study on high-performing teams found that this was the common element that all the best teams shared. This principle entails the freedom to experiment and try new things, and the knowledge that you won’t be punished if the experiments fail or for honest, well-intentioned mistakes. Let’s explore the intersection between the importance of innovation at a young, bootstrapped company and the psychological safety required to innovate.
Balancing Innovation and Safety
I was recently the founder and CEO of a bootstrapped software company staffed by a heroic engineering team. They worked seven days a week on startup hours and even showed up without complaint for a company onsite on Memorial Day. (In my defense, I had no idea I’d scheduled it on a holiday. When you’re in the startup grind, you can completely lose track of the date in the outside world.) They were working at an inhuman pace to get our product — submillisecond anomaly detection software for large-scale networks — out the door.
Our senior architect approached me one day with a proposal to future-proof our product. He suggested porting our software to a different operating system. Technical readers will understand this isn’t a minor suggestion. It requires a rewrite of the codebase and extensive testing. His rationale was well-reasoned: He believed the current operating system would hit a maximum network performance level in a few years and that the software would be more stable on the new OS. He’d spent his precious few off-hours experimenting with a prototype of the new OS and asked to schedule a company all-hands to discuss his proposal.
I had to quickly recover from the (internal) shock. I imagined customer and investor conversations to allay their fears when they saw the new, delayed timelines and associated costs. Revenue would now be kicked significantly further down the road, while our runway was going to increase slightly as a result of testing the new code. But I didn’t want to let those considerations get in the way of nurturing a company culture that was open and safe — and, more importantly, his ideas made sense. If this was the right decision for the company, I’d gladly have those conversations as the CEO.
Before the all-hands discussion, the engineers engaged in deep conversation and research about networking trends and speeds, the future of networking (including 5G, although it was still several years in the future at the time), and how a possible OS port would play into our patent strategy and add value to the company. It quickly became clear that the entire team was thinking strategically and long-term about the company and its valuation.
The conversation itself was calm and collaborative. It involved a lot of stakeholders, including our internal and external QA teams. I made sure that everyone had an opportunity to express their thoughts and concerns about the code port, including a few people who didn’t initially support the suggestion. It’s important to ensure that everyone feels safe and heard in these situations by ensuring that their ideas and input are carefully considered even if they’re in the minority.
We ultimately made the decision to port the code. I updated our investors and customers and explained there would be implications on both deliverables and resources. My team knew I trusted them and that I fully supported the decision. When customers expressed concern about delays to engineers — who were on the frontline of communication with them — I stepped into the line of fire and reiterated why we’d made the decision and how it would ultimately benefit them with higher performance and stability. As CEO, it’s critical to support your team and take incoming fire over decisions that have been made as a team.
What If We’d Made the Wrong Decision?
We took a calculated risk with the decision to port our codebase. Our senior architect wasn’t putting our main codebase at risk by tinkering with the new OS on extra servers in our lab. He also prioritized urgent deliverables so that the company didn’t lose customers or investor funding. He experimented in parallel with his core responsibilities and didn’t touch the live product in customer environments. He felt safe coming to me with his suggestion and knew that if his exploration was unsuccessful, there would be no repercussions. We’d still meet customer deadlines and our core product roadmap would still be on track.
The suggestion to move to a different OS grew out of the team’s technical knowledge, years of experience, and studies of the market and trends. The decision itself was ultimately based on everyone’s gut intuition that it was the right call.
Had it turned out to be the wrong choice, we could have reverted to our previous code. We would have lost significant resources and time, but it wouldn’t have been a fatal or unrecoverable error. It was a big bet, but we didn’t bet the whole company. OK, we bet a lot of it. But we made the decision with a great deal of data, intuition, and trust.
Two Critical Lessons: Encourage Exploration and Psychological Safety
There are two important lessons to take away from this experience.
First, when you’re running a resource-constrained company, it’s scary to think that your small team is tinkering outside your immediate deliverables and deadlines. In hindsight, had my team not been exploring both outside the box and our immediate roadmap, the company would have been less competitive in the long run. And it would have impeded creativity and freedom in our engineers, ultimately making them less happy and satisfied. Although doing so is scary, it’s important to encourage innovation outside your immediate deliverables. Your company will be more competitive and nimbler, and your team will be happier.
Second, you can’t foster a culture of experimentation and innovation without psychological safety. My personal leadership style is bold, trusted, authentic, and underscored by empathy. Everyone who works for me knows they are empowered to explore and try things and then bring them to my attention. Even though we didn’t have an explicit mandate of 20 percent exploration time like Google, and we were incredibly resource- and time-constrained, the team still felt free to innovate and try new things. They knew that, if they tried something and had good reasons for trying it, there would not be repercussions — even if it failed. It’s critical that you create a safe and trusted environment where your team can experiment and innovate.
These are the kind of leadership decisions I’d make again and again, in a heartbeat. I encourage you to as well.
