Startups and enterprises think differently — and for good reason. A business with 10 employees can move much more quickly than one with 10,000. Enterprises often support vast troves of legacy systems and have an existing client base to serve. And though they typically have more money at their disposal, they get a bad rap for being rigid, less innovative, and prime for disruption.
So in hopes of remaining competitive, stakeholders and C-suites often pressure enterprise IT teams to act like startups. Sometimes the mentality shift works: Phil Wiser, CTO of CBS, transformed his former employer, Hearst Communications, as CTO from an enterprise to a startup mentality over the course of six years, he says, a transition that made tech operations more profitable. At insurance firm Liberty Mutual, CIO James McGlennon agrees, saying that startup thinking improves “automation and optimization from an efficiency perspective” and helps a company stand out from its competitors.
A startup mentality may not be beneficial for every organization. But if your team is looking for that startup edge, here are several key steps and methodologies from IT leaders who successfully made the shift.
Determine whether change is actually needed
Catchphrases like ‘fail fast,’ ‘pivot,’ and ‘break things’ make startups sound cool, but that doesn’t mean larger companies need to embrace them. Debbie Barta, senior vice president of innovation and startup engagement at Mastercard Labs, cautions executives against moving into what she calls a “bipolar” mentality of startup good, enterprise bad: “It’s not extremes,” she says, explaining that there are pros and cons to both large and small operational mentalities. For example, Barta says, the fact that corporations are more established makes them better at avoiding risk, whereas startups are more skilled at “creating nimble, agile technologies.”
At Mastercard Labs, Barta strives for the happy middle, identifying “things that we can learn from startups and the mentality and the agile nature of what they do,” then runs the idea through the more mature corporate lens. Newer projects such as blockchain, augmented reality, and internet of things are “things that are perhaps more assumptions than knowns,” she explains, “things that are slightly more risky, that require us to be in a more nimble agile mode to test and learn.” So look critically at your projects to determine which ones need a revamp and which ones don’t.
When Liberty Mutual’s McGlennon assessed his organizational needs, he realized that all development needed to speed up: “We figured out that the overall approach to building software with the waterfall methodologies and the stage gates and requirements, followed by design, followed by development, followed by test, followed by blah, blah, blah was way too slow.” As a result, Liberty Mutual transitioned 88 percent of its tech work to agile.
Embrace and spread change strategically
It’s easy to look at that 88 percent and assume Liberty Mutual simply hasn’t moved over its remaining projects yet. The present shift, McGlennon says, has taken four or five years. “[There’s] the scope, the challenge with transforming and … the reskilling essentially of a 5,000-plus person team,” he explains, “It’s kind of a battle and a challenge every day.”
But the 12 percent of projects still using waterfall have been left that way intentionally. McGlennon’s end goal is to eventually have all teams on agile, but in the meantime, Liberty Mutual works with 4,000 to 5,000 applications, many of which, such as legacy mainframes, are decades old. These programs “don’t lend themselves to continuous integration [and] continuous deployment pipelines,” he explains, and weren’t built to easily transition. But with the company’s enterprise resource planning (ERP) software, human resources technology, and other back office systems now under agile, McGlennon says, “We can see the solutions coming alive very quickly.”
Liberty Mutual’s remaining waterfall developers are working iteratively, though, in squads and in smaller, multifunctional teams. McGlennon also removed the communication and operational barriers that used to separate the insurer’s business and technology groups. Even developers who aren’t using agile are asked to think that way, focusing on “what the priorities were and [the need to] be okay with changing them if that’s what the data said,” McGlennon says. “We wanted to make sure that we tried to instrument our technology to understand the feedback and scale it if it worked or turn it off if it didn’t.”
Here, quick wins help make the business case. “When you’ve got a fully depreciated system sitting somewhere and you go to the president of that group and say you need to kick that out and put in this new system, it requires them to internalize the value of that ongoing change,” CBS’s Wiser says. Tech leaders have to prove the changes they need are smart, not just technically, but financially. “Any division that wants to not adopt what you’re bringing can develop an economic reason not to do it,” he adds, so be prepared to give them a better one.
In the end, if the business case doesn’t convince C-suite, try security. According to Wiser, “One of the biggest threats in terms of cybersecurity are outdated software systems.”
When startups split focus, they die. Public perception may be that they’re venture capital-based with investments overflowing, but only six percent actually receive outside funding. Most startups operate only from the money they make. They can’t afford to develop multiple projects at once.
Similarly, Wiser says, if enterprise tech tries doing too much, it too will fail. Not because the company doors will close, but because projects won’t get the buy-in required from upper management. “Communication is key and that really requires focus. If you go in and you have your list of 20 big objectives for the year, you will absolutely fail,” Wiser says. So instead, he recommends tech executives “be very systematic picking one transformation at a time.”
As a conglomerate, Hearst is so large that it has 50 CTOs. Wiser’s role was to oversee Hearst Communications, a technology-only division that developed projects which it then ‘sold’ to Hearst’s business units. While pursuing blockchain and other buzzy tech was tempting, they simply couldn’t do it. To prioritize, Wiser divided projects into one of four categories: explore, watch, prototype, or cash flow investment. This enabled Hearst to keep an eye on tech it might need in the future, while keeping focus tight.
Build more, develop less
When you have a large tech staff in-house, it’s tempting to just build the applications that you need. After all, any company knows its needs best, and internal software customization can prevent feature bloat while making sure new tech meets business needs. But McGlennon says don’t, because you may not always need to.
Take chatbots, for example — technology that can take months or years to develop from scratch, says Ashok Kumar, CTO of digital transformation at Verizon. Verizon has spent a decade building multiple bots, but startups don’t have ten years. To save time, they typically piggyback off existing tech. So when Liberty Mutual wanted to build a single chatbot for consumer claims, engineers used Amazon Web Services products Lambda, Connect, and Lex to speed ahead. Today the bot processes more than 150,000 customer calls per month.
Go minimal before overcommitting
‘Build fast, fail fast’ sounds corny but it’s startups’ mantra for a reason: Just as smaller companies can’t afford to split focus, they don’t have time to build the wrong thing. Instead of perfecting software before they release it, startups build minimum viable products (MVP). Their user interface is often rough and these elemental versions don’t have any bells or whistles, but they do give startups something to quickly launch in order to learn from early market response.
For engineers who are used to presenting the boss with something perfect, this isn’t easy. McGlennon says, “You’re talking about drastically changing people’s behaviors and setting new expectations for what’s okay” by adjusting their daily tools, processes, and approaches “and it’s difficult for everybody to embrace those all at the same time.”
To help staff get comfortable with the change, Liberty Mutual set expectations early, telling employees “that it’s okay if we fail on different things,” says McGlennon. But he also says tech leaders clarified their teams’ new expectations: “We start building software earlier — meaning almost immediately when we begin to understand what we’re trying to do — and we don’t spend months on end laboriously articulating exactly what it needs to be and how it needs to work.”
As a result, Liberty Mutual built a motorcycle insurance customer platform in 28 days — a definite MVP, according to McGlennon, but a quick way to determine whether policyholders would use the product. “You need to have some examples,” he says, “flagships that you point to that help people understand how things can improve and embrace the approach that they can do it too.”
After all, if there’s one more lesson to learn from startups, it’s that success begets success.