In the first post, we addressed what startups can learn from enterprise software companies, but in this post we’re focusing on what enterprises can learn from startups. There is a reason startups outexecute the good ole’ enterprise, but let’s find out why.
Disclaimer: If decision and policy-makers are your enterprise are stuck in their ways of building product or service, and are not interested automating or simplifying processes to reduce administrative overhead, promoting change will be a tough road for you. If leaders are too focused on the way things “have always been done” and not on removing every possible barrier to help the customer succeed more quickly, you’ll be fighting an uphill battle. I’m assuming you already have a heavy amount of process, policy and your waterfall product development style create a really long feedback loop.
Let’s begin to ask the question: “what is true about a startup that helps them be so agile, so innovative and so good at serving customers well?”
High trust environments unlock creativity, speed, and innovation
Something you see built into the DNA of many startups is a high degree of trust in their employees to build products and services responsibly (note: this is not always true, but often is the case). Enterprises must extend higher degrees of trust while maintaining guardrails that protect them against anomalies. One way to maximize trust is to limit the number of approvals needed to get something done. Ask yourself, “What are we really afraid of that we need so many groups to sign-off on something? What can we do upfront to further educate and enable more staff to self-regulate given the principles?” More on trust is in this great book called The Speed of Trust, and how low-trust environments cost more money and slow down innovation for a company.
Teams work in close proximity with the customer
At VendorHawk, we often said, “Everyone is in sales & customer success!” This meant that we often had developers on the calls with customers while reps were showing new features and getting feedback on them. Some developers might not have the ability to talk smoothly to customers or might dive too deep into the technical weeds. I would recommend two things to help on this point:
- Enable devs with basic level sales training on how to discuss capabilities with customers, fighting the urge to delve into tech stuff, or exactitudes of the product.
- Require devs to listen to pre-recorded customer demos at least once per month to stay in proximity to what customers are saying. Over-reliance on product or sales folks to rely on the insights second hand can lead to skewed interpretations of the customer’s real pain.
Shorter feedback loops enable quicker innovation
There are two flavors of a shorter feedback loop.
- From a software engineering standpoint, automated test frameworks that give near immediate feedback on the quality of a build is a must. That helps with increasing code commit velocities and cycle times from days to minutes.
- From a customer standpoint, how long does it take for your customer’s input to go into a new release? Most legacy software companies have moved away from their 18-24 month release cycles, but some are still locked-in at once or twice a year. If you’re running product at a large enterprise, find ways to get early feedback from mock-ups and quick surveys to let the customer’s voice be heard. Customers can help you prioritize their asks so you can respond to their most important needs first. I’ll write another blog on prioritization of roadmap in a future post.
Less time planning, more time building & serving customers
Enterprises are tempted to meet about everything and do very little. Startups are quite the opposite. Many startups do a daily 15-minute stand-up meeting and prefer to be building rather than pontificating about their estimates. The more that executives demand insight and forecasted product releases (like waterfall style planning), the more time teams waste adding up story points, doing spikes and debating about a guess on effort, which is almost certainly going to be wrong in the end anyway. If enterprise execs could live with less information up front, teams could gain another sprint (or two) by cutting back on planning and do just-in-time meetings for issues that arise that cannot be addressed in a standup. Not to mention, builders can build instead of practice their reading of crystal balls for executives.
Focus on removing every roadblock and pain in the customer experience
One reason why startups usurp incumbents is the speed at which customers can get to value. They don’t have long demo processes, or buying cycles, or labrous implementions and the like. I know enterprise processes comes from all the baggage of situations that lead to “we need to have a rule to make sure this doesn’t happen again”. Obviously, large enterprises that have 1000 sales reps globally need more process than a startup that has only 10 reps in one location; but startups are often better at spotting areas of friction with the customer (in the product, implementation or overall customer journey) and relieving the pain.
At VendorHawk, we noticed that customers needed a simple way to answer all the security questions about our product, so we created all the necessary documentation to help streamline the process of answering those inevitable questions. This helped remove roadblocks to help customers buy our product.
Developers are responsible for their own quality, not a separate team
Many times, a well-intentioned decision to have a large quality engineering process can lead to incentivizing developers to give all their bugs to another team, especially when there are planned several sprints exclusively for fixing bugs. LEAN startups realize the onus of quality is on the developer and the reviewing developer peer – not some other quality team in the business. This is part of why writing good automated tests really matters. If you’ve set-up a large quality process and baked several sprints into the release just for quality and not innovation work, you’re setting yourself up for tempting devs to ship more features with lower quality. This causes teams to scramble to fix all the bugs later, instead of shipping clean code now. If you must have a quality team with several quality sprints, consider rewarding teams with clean builds to have one more innovation sprint to work beyond the normal deadline.
Bias towards action & ownership
A trademark of great startup employees is the decisive “self-starter” who knows how to get things done. This doesn’t mean they go rogue and run off with no guidance and no accountability. But on the flip side, employees at larger companies get comfortable with responses like, “I’ll need another week to look that over”, or “I’m still waiting for so-and-so to review that and provide their feedback before we regroup.” While feedback is good, dragging out a decision is another reason why you lose to startups. Startups empower their staff to get aligned on the goal and approximate approach and lets the team execute their way to a result (or at least a solid first draft). In product, land, I’m describing a working prototype. In sales land, an example would be testing out a new email campaign and some new collateral that helps turns customers heads.
For example, at ServiceNow, I’m working in a remote office that has considerably less attention than the flagship offices, so our company brand and values are not yet prominently touted. I’ve seen the gap between stated company culture and remote office life and rallied some other managers and directors to take action, with help from central HR. I feel a sense of ownership for our office’s culture and my part to connect it to the greater whole of the company. No one in HR or communications ask me to do this, but I can’t help but help. That’s a bias for action.
This list of seven tips is still just scratching the surface of things enterprises can learn from startups, but I trust this was insightful and inspiring for at least some of my readers.
Patrick Lowndes 