The Myth of the Startup in a Large Company

I was reading this 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 so many times from recruiters, from 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 sought. The result is usually a whole bunch of wasted money and angry employees who felt like they were promised a bill of goods.

Stewart Butterfield, discussing his experience selling Flickr to Yahoo:

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.

This is talking about the inverse problem, but it comes down to the central crux of the issue at large companies: resource contention. This is beyond innovator’s dilemma.

In a startup: all of your attention is spent 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 short-cuts in other areas just to get the product launched. You are fighting for your life and your income, and you will do whatever it takes to get there. Why do you do it? Because you love the energy, or because you 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; there is a brand to build off of; there is the promise of a paycheck no matter what the outcome. It is these conditions that destroy the innovation.

There is a mature infrastructure, but maybe it is not a great fit for what you are trying to build. Maybe you just need some small tweaks, but the infrastructure team is primarily focused with serving the existing teams that bring in the revenue; it will be hard to get your needs prioritized. Maybe you can even prototype or launch with your own skunkworks infrastructure; that won’t last for long. The corporate infrastructure is vetted, financed, regulatory compliant, and 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. This means that instead of focusing on building your product, you are instead focusing on getting internal support. Maybe you launch under some new secret brand. This may work for a little while, but if you are successful, there will be increasing pressure to join the fold. And in any case, launching under a secret brand basically kills the benefit of the 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 very little ownership in the outcome. It isn’t “your” product, it is your corporations’ 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, and that is pretty 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. Because you are part of a larger (presumably already profitable) parent, you will be restricted from certain business models: 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. Amazon, with their don’t-ask-us-about-profits model could never have been created as a division of Microsoft. The shareholders would have rebelled.

If you don’t succeed quickly, your team’s resources will be coveted by the teams around you. 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, or take over your team, or switch you onto the “official” technology stack, or just 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 where there is an established business. Being slightly profitable is a huge win for a startup; being slightly profitable is a major 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 multi-national 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; instead 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 Company X will own a significant stake as well, plus some non-exclusive licenses on the IP. Allow them to recruit from your company, but they will no longer be employees of Company X. If the venture fails, they may be able to interview to rejoin Company X, and they may get to 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.

By sponsoring your own employees, they are likely to build in a compatible way with the way your company works, 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. In the end, you will get the innovation you want, and probably cheaper than if you tried to fund it from within your own cost structure with all of its overhead.

[This post was updated on August 23, 2014. Nothing was removed, but I added some more thoughts about business model limitations and startup success levels not matching the expectations of a more established company]

My Slides From My BBC Develop Keynote

I had a great time at the BBC Develop conference in London this week. The BBC were gracious hosts, the audience had some good (and not too easy questions) and the program had some really good talks; so I learned quite a bit and met some excellent folks. Special thanks to Tanya Rai, Colin Savage, and Simon Stevenson at the BBC for inviting me and putting on a great day.

What do I look for when hiring an engineer?

I’m don’t spend much time on Quora, but I was reading a different thread and I came across the question: What Makes a Software Engineer Good? Now anyone who has worked with me can tell you that I am pretty opinionated about this subject. So since there wasn’t already someone saying what I would have, I decided to post an answer. Here is that answer:

I’ve interviewed literally hundreds of software engineers over the last couple decades for my teams at Microsoft, Adobe, Spotify and other places.

Over the years, I’ve honed in on a few things that I consider vital for anyone joining my organization. These are the kinds of things that I value as a hiring manager, of course. Others will have their own critical criteria.

These are in a rough priority order.

1) Pragmatism
I don’t bother with tricky or difficult programming questions designed to test a corner of your knowledge or some trivia. Instead I ask a dead simple question. Something anyone could do. Then I complicate it. And complicate it again. And again. I look for the point where you can no longer adapt your very first answer. What I want to know is that you are willing to throw away your first answer when it no longer makes sense. You’d be amazed how many engineers will hack on something that will never work when they could throw it away and do something much simpler in a quarter of the time.

2) Interest
Do you actually like writing code every day? Do you read programming blogs for fun? Do you work on your own coding projects outside of work? If this is going to be your job, I want someone who is overjoyed that they get paid to write software. Not someone who’d rather be doing something else.

3) Attitude / humility
I’ve worked with brilliant people who are jerks. For every inch they moved the product forward with their innovation or genius, they moved the project back two inches by being impossible to work with. I want someone who is there to make the team better, not someone who feels like everyone just “needs to do as they are told.”

4) Intelligence
Yeah, you do need to be smart. Writing software is part art and requires creativity, but it is also a lot about problem solving and just sheer brainpower to figure out why this thing is crashing, but only on Tuesday when the moon is full.

5) Programming languages / domain experience
I have worked professionally with a dozen or more programming languages. Some I don’t even remember anymore. While I have a lot of depth in some of them through years of experience, I have been able to learn others as I need to in order to suit the project. I would prefer to see someone with some proficiency in more than one language because that shows some breadth and a willingness to learn, but as long as you can code and are smart (see #4) you can probably pick up whatever language we are working in reasonably fast. I hire for the long term, we can take a bit longer to get you up to speed if you’re a good fit. Similarly with domain experience. If you have an aptitude, we can teach you.

I do have a couple caveats to #5 though:
If I’m hiring for a senior position that requires domain knowledge, yeah, that is in the job requirements, so you need to bring that. You would still need to handle 1-4 though.

On languages, there is a major caveat. If we’re doing C++ or C, you’ll need to have some experience there. If you’ve only ever worked with high-level, garbage-collected languages, it will simply take too long to really bring you up to speed. I’ve tried this too many times in the past and have realized that it usually isn’t worth the effort.

Some upcoming talks (Stockholm and London)

Since getting to Spotify, I’ve been thinking a lot about what makes a good engineering culture and the best way to create, nurture and protect it. There is no simple formula, but I’m starting to understand better the things that have worked well in both the small startup teams I worked in as well as the big corporate ones. I’ve got two talks coming up where I’ll outline some of these thoughts. I hope that it will be insightful or inspiring to others. At least there will be some amusing anecdotes 🙂

I’ll be doing a short talk on Thursday next week at Valtech Days in Stockholm. My talk is specifically on doing real work using Lean and Agile techniques, based on my experiences building products at Microsoft, Adobe and Spotify. The line-up looks really great. It will be an excellent event.

On November 12th, I’ll be keynoting the BBC Develop 2013 conference in London. This will be a much longer talk where I go into the Spotify model of Lean and Agile development, and how it has grown a strong engineering culture. This event looks really awesome. It should be a really informative day. I’m really looking forward to it.

I’m not sure if either of these will be recorded, but I plan to continue talking about this as I keep working on these issues at Spotify. So if the subject is interesting to you, but you can’t make it, stay tuned.