The Myth of the Startup in a Large Company
Witaj świecie! (Hello World in Polish)
As always, I hope all is well with all of you. We’ve had quite a few new people subscribe over the last month. Thank you! If you are new to the newsletter, please check out the archives on Substack. Of course, you can always buy the book.
About this newsletter
If you are new to this newsletter, here’s what makes it unique. Every two weeks, I share a chapter from my book It Depends: Writing on Technology Leadership 2012-2022, which Unit Circle Press released in March. These chapters are not in sequential order, but each one is a standalone piece. In addition, a podcast serializes the audiobook in order, released in the alternate weeks from this newsletter.
The Latest Podcast
The latest episode of the podcast is “What do I look for when hiring an engineer?” This episode was fun to record because I described the questions I used to ask developers, which I didn’t include in the original article for length, and also some interviewer horror stories. It is worth a listen if you are interviewing for your company or as a candidate.
You can get the episode at Apple Podcasts, Spotify, YouTube, directly via the RSS Feed, or wherever you get your podcasts (see pod.link for a more extensive list).
Drop me a line
I’m always eager to hear from you. If you have questions, want a signed copy, or simply want to say ‘hi!’, please email me at contact@itdependsbook.net. You can also share your thoughts on Substack or the various podcast platforms. Your feedback is invaluable, and I look forward to hearing from you.
About this week’s chapter
This week’s chapter title is “The Myth of the Startup in a Large Company.” It describes the lessons I learned after leaving as an executive from a large company where I led a new product incubation effort to take an executive role at a startup. The large company had struggled for years to build new products that could either gain traction or compete with existing competitors. My last job at the company was as the engineering leader of one of these efforts.
We did well, up to the point where our success incited the leaders of the existing products to co-opt our efforts to either help their products, move to their infrastructure, or leverage our infrastructure to improve their products. After that, our progress and ability to innovate were hampered by meetings, debates, and other teams trying to influence our feature development. My experience leading that organization influenced my decision to leave and go to a startup, even though I loved the product and organization we’d built. The product survived for a couple of years after I left, the eventual victim of corporate antibodies. It wasn’t a product/market fit problem as one of our competitors who came after us in the market copied the feature set and took on some of the team. It remains incredibly successful with many millions of users.
This is chapter 35 of It Depends.
The Myth of the Startup in a Large Company
Originally published on August 10, 2014
I was reading a post from John Gruber, which had this paragraph in an ad for the iOS development team at Google:
My thanks to Google — that’s right, Google (kind of awesome, right?) — for sponsoring this week’s DF RSS feed. They’re hiring developers and designers for their iOS app teams, which operate like a start-up within the walls of Google.and I thought about the number of times I’d heard that line: “Operates like a startup within <insert large company name here>” or “Operates like a startup, but without the risk.” I’ve heard that line many times from recruiters or friends. To be honest, I’ve even said it myself a few times, trying to sell a prospective candidate who I was trying to woo away from a startup.
That notion of working like you are in a startup but being part of a much larger organization is a myth. Anyone who says it is naive, disingenuous, or just plain wrong. Large companies that try to build those kinds of teams, be it “innovation lab,” “startup experiment,” or “corporate startup incubator,” usually fail to achieve the innovation or energy they seek. The result is typically wasted money and angry employees who feel they were promised a bill of goods.
Stewart Butterfield, discussing the experience of selling Flickr to Yahoo said, “They sold out to Yahoo assuming that they’d be backstroking in rivers of money and terabytes of memory. Instead they had to fight for everything: servers, people, time.”
Butterfield is talking about the inverse problem, but it comes down to the central crux of the issue at large companies: resource contention. It is a problem beyond the innovator’s dilemma.
In a startup, you spend all of your attention on finding the right product/market fit, finding customers, finding a flow of income, and/or finding investment. You will make the trade-offs you need to get your product off the ground. Often, this may mean choosing poor technologies in the short term to help you get going more quickly. Your resources are limited. You need to make do to get going. Maybe you will take some shortcuts in other areas just to get the product launched. You are fighting for your life and income and will do whatever it takes to get there. Why do you do it? Because you love the energy or are looking for the fiscal payoff. No risk, no reward.
In a big company, you don’t have to make those trade-offs. There is probably a very mature infrastructure to build on, a brand to build off, and the promise of a paycheck, no matter the outcome. It is these conditions that destroy the innovation.
There is a mature infrastructure, but it may not fit what you are trying to build. Maybe you just need some minor tweaks, but the infrastructure team primarily focuses on serving the existing groups that bring in the revenue; it will be hard for them to prioritize your needs. Maybe you can even prototype or launch with your own skunkworks infrastructure; that won’t last for long. The corporate infrastructure is vetted, financed, and regulatory compliant. They own their turf and don’t appreciate someone jury-rigging something else.
There is a brand, but that brand is well-known and highly controlled. You can’t launch just anything using that brand. It needs to be vetted. Instead of building your product, this means you focus on getting internal support. Maybe you launch under some new secret brand. This may work for a while, but if you are successful, there will be increasing pressure to join the fold. And in any case, launching under a secret brand kills the benefit of being part of the parent company.
The lack of risk is its own deterrent. Knowing that you get the paycheck is nice, but it is also understanding that you have little ownership of the outcome. It isn’t “your” product. It is your corporation’s product. You are just one of the people on the team. While you may still put in startup hours for the joy of it, eventually, you will realize that you aren’t getting the startup reward for all your hard work, which is demoralizing.
The general problem is that even if you have the deep pockets of a large corporation backing you, you don’t have the ability to do what it takes to survive. From the minute the project is launched, you are on a clock. You will be restricted from specific business models because you are part of a larger (presumably already profitable) parent. It’s hard to justify spending a few years taking substantial losses to scale your business quickly when you are seen as a drain on the profits of your parent company. With its don’t-ask-us-about-profits model, Amazon could never have been created as a division of Microsoft. The shareholders would have rebelled.
If you don’t succeed quickly, the teams around you will covet your team’s resources. They are like vultures waiting for you to fail, and they will rush to declare you a failure as early as possible if they think they can benefit from it.
If you are successful and start to grow, you have the same problem. Teams will attempt to co-opt your mission, take over your team, switch you onto the “official” technology stack, or flood you with resources trying to get some of your “startup” energy.
If you are successful by startup standards, that may not be seen as much of a success in a larger parent company with an established business. Being slightly profitable is a huge win for a startup; being barely profitable is a significant loss for an established corporation.
So, how can you create a startup in a large company? I think the university model is an interesting approach. Say you are Company X, a large multinational technology company, and you are constantly challenged by your inability to move at startup speed or innovate. Instead of creating a startup team inside some division, create an actual startup.
Solicit pitches from your entrepreneurial employees. Pick one or more, and fund them as independent companies. Give the founders an equity stake in the new venture, but your company will also own a significant stake, plus some non-exclusive licenses on the IP. Allow them to recruit from your company, but they will no longer be employees of your company. If the venture fails, they may be able to interview to rejoin their former company, and they may get some of their benefits back, but there is no guarantee of employment. Also, get them out of your building. Allow them to raise outside investment if they need it.
By sponsoring your employees, they are likely to build in a compatible way with your company's work, given that it is their training. They will know your industry. They won’t be complacent because they can’t afford to be. They will also be invested because they will directly benefit from their success. Ultimately, you will get the innovation you want, probably cheaper than if you tried to fund it within your cost structure with all of its overhead.
Upcoming talk
I’m giving a talk, “The path from Director to CTO: How to follow it, or how to mentor it,” at the LeadingEng conference in New York City in September. You can use the code “DISTROKID” to save 10% on your registration! More information and registration: https://leaddev.com/leadingeng-new-york
Thanks again for reading! If you find it helpful, please share it with your friends.
Buy on Amazon | Buy on Bookshop.org | Buy on Audible | Other stores