From big-tech to startup by way of the kitchen

Developers often get pigeonholed, not just into technologies but into the types of companies they work for. If you start out working on financial back-ends for banks or join Microsoft fresh out of college, it is all too easy look up from your cubicle a decade later and realize that you haven’t seen the world. I’ve been fortunate enough to work in several radically interesting and different environments, from special effects studios, to traditional software companies, to professional kitchens. At each stop I’ve learned how to be a better engineer, how to contribute to different types of teams, and, maybe most importantly, about myself. My hope is that by describing my own trajectory and experiences, I can help you figure out whether you should consider giving up your comfortable career at a big company for something as mad as a startup.

I started programming back in the 1970s at the age of 12. My dad brought home a model-33 teletype that was connected to the Louisville Board of Education’s Honeywell mainframe, where I could write code in BASIC. Yeah, it was a freaking printer, with a 110-baud modem, and a paper-tape reader. And I was in love. Since the statute of limitations has long since expired, I don’t mind telling you it wasn’t long before I was hacking into computers all over the country — for the pure love of the puzzle. Next came DecSystem-10 assembly programming, and over the next few years I would hang out at Radio Shack stores and the University of Louisville Apple labs — anything to get my hands on computer time. By the time I was 16, my friend Dave and I had a contract to develop accounting software (with a surprisingly sweet user interface) that ended up being used for decades.

When I went off to Brown, I hoped that the years of coding under my belt would give me a leg up in the Computer Science department, and it did. I joined Andy Van Dam’s computer graphics group as a freshman, and through that, plus a short stint at UC Berkeley, I made friends that led to 20 years of awesome jobs. If I could tell a young developer one thing, it is that pouring your heart into your work and building great relationships in your career will always open doors for you. I don’t mean that you need to be calculating in how you make friends, simply that if you devote yourself to be a first-rate programmer and a reliable teammate, your friends will want to work with you again wherever they land.

My first stop after college was Industrial Light & Magic. I showed up for the interview in a suit, but they hired me anyhow. My friend Eric was the first full-time programmer there and I was the second; prior to that, they had technical directors writing code, which was a scary thing indeed. On my first day at ILM, I got to be on set when the practical effects team blew up the giant warehouse model for Backdraft. During my stay, I worked on Terminator 2 and Jurassic Park, and loved collaborating with artists and directors. It was high pressure fun: “We need a way to make the T-1000 morph up out of the floor, but if you can’t figure it out by tomorrow morning, I guess we’ll just animate it by hand”.

Moving on from ILM to Silicon Graphics was a big decision, but in spite of the excitement of the movie business, I was tired of 80-hour workweeks and ready to move on. SGI machines were the workhorses of computer graphics in those days, and once again, I had close friends working there. I joined a team building a set-top box with a ridiculous 3D interface. I had just moved to Milwaukee so I was doing an early experiment in telecommuting and thought it was pretty glamorous to be in my mid 20’s and taking fancy business trips all the time — including the first of several trips to Tokyo because our initial deployment was with NTT. When the set-top box went down in flames, I joined the VRML/CosmoWorlds team that made an early, valiant, and hopeless attempt to bring a 3D graphics standard to the web.

It turns out I had joined SGI when both the stock price and hubris were at an all time high. When competitors like NVidia started making graphics boards that were an order of magnitude cheaper, we thought they were toys. While SGI was busy sponsoring Hollywood premiers and its executives were holding company meetings with increasingly dubious levels of fanfare, those competitors ate our lunch and hired away most of the best engineers. I don’t regret my years there at all, but I learned a few important lessons: (1) having the best technology doesn’t mean you will win — and your technology probably isn’t as far ahead as you think it is (2) if what the execs are saying sounds like BS, it probably is and (3) don’t be the one left behind to turn the lights out.

Adobe was an entirely different situation. I spent 12 years there as one of the lead engineers (and, briefly, engineering manager) on the After Effects team. After Effects started out as its own small company (CoSA), founded by a group of engineers that I knew from Brown, and then it was acquired by Aldus and in turn snapped up by Adobe. In fact, funny story, when they first started building After Effects and I was at ILM, the team came by to show it to me and my first reaction was “this will never work.” I couldn’t have been more wrong. It grew into a professional tool that hundreds of thousands of people around the world love and use to make their living.

My time at Adobe reflected pretty much everything that could be great about working for a big company. I doubt that 1% of engineers have a situation that good. Especially in the early years, we had the best of both worlds. The After Effects team was pretty much autonomous. We knew our customers and built what they needed. We had ownership of our product and control of our destiny. We were a tightly knit bunch that spent lots of time with each other (and later, each other’s families) outside of work. My teammates were brilliant, and we knew each other so well that I think we could communicate whole designs with the raise of an eyebrow. At the same time, the larger company added tons of value. We had job security and stability, great benefits, and work-life balance. And because Adobe makes Photoshop, Illustrator, and Premiere, we got to build best-of-breed integration with those products, using the same core libraries they were built on.

And yet….

There were still things that gnawed at me. Big companies can’t help it. There are boring corporate meetings, and increasingly irritating product requirements that come down from on high. Executive whims and people scrambling to figure out which way the wind is blowing and align with it. Corporate buildings are still corporate buildings even when they have really well-stocked candy jars. HR processes so tedious you can actually feel your hair turning gray. Reorgs that left you needing a frequently revised cheat sheet to remember the path from you to the CEO.

When you are building desktop, shrink-wrap software, builds and QA and deployment is generally a pretty painful process. We got used to shipping every year or 18 months; even with agile processes there would still be months of excruciating bug fixing at the end of each cycle. And worse, build times could often be 10 or 20 minutes. It is pretty hard to get in the flow as a programmer when you are interrupted for that long on a regular basis.

And then there is innovation. Adding a cool new feature to After Effects? No problem at all, I could make that call myself, or over lunch with the team. But starting a new product? You’d better have some serious fortitude because you’ll need to go through N levels of executive review, and you’ll need to prove that it could generate tens or hundreds of millions of dollars in revenue. Because anything less than that isn’t going to move the needle. Worse, you’ll need to keep proving the same thing every quarter, because incubating a team and a product takes a long time and corporate memory is short. All big companies talk a great game about innovation, but it mostly goes against their inherently conservative DNA.

Let me be clear, this has nothing to do with Adobe. The same is true at Amazon or Apple or Microsoft or Google (or Boeing or Ford or Bank of America). But there came a point when I knew it was no longer the best fit for me.

I had always had a great love for the creativity and physicality and human connection of cooking, but it never seemed like the right time to take the professional leap from the keyboard to the kitchen. So in 2007 I started a blog as an outlet for that passion. While I was still at Adobe, I took time off to stage at a few restaurants, and the blog led to an opportunity to write a cookbook, which became a finalist for a James Beard award.

When the book was published, I took that as an impetus to leave Adobe, do a book tour, and begin planning my own restaurant. I was excited (and, obviously, terrified) by the unknown in front of me. And still, leaving was painful, primarily because I knew I would no longer see some of my closest friends on a daily basis.

And then a funny thing happened on the way to that hypothetical restaurant.

It was November 2012, and I was in hot pursuit of the perfect space to set up my $35-per-plate, lunch-only modern vegetarian concept. Sure, the numbers weren’t exactly penciling out but I was determined to make it work. In my morning spin through the web, I saw a note about a startup called ChefSteps that was going to teach the world about cooking sous vide, with alumni of the Modernist Cuisine team as founders. I had read Modernist Cuisine cover-to-cover and was fond of filling my kitchen with the comforting smells of locust bean gum and sodium hexametaphosphate, so naturally I reached out. My first pitch was “Hey, I’m a food blogger, want me to come write a piece about you?” Answer, in translation, “Meh.” My second pitch was “Oh, by the way, I also write code.” Answer, “Can you be here tomorrow at 10?” No translation needed.

The courtship was short and intense. The first week I was hanging out, I built a feature that their contract development house had claimed was more or less impossible. The next week we fired the contract developers and I signed on as CTO.

This was a pretty big gamble on everyone’s part. My knowledge of web programming was indistinguishable from zero. I spent a few days with the contract devs before we let them go, and they would say things like “to configure SSO we need to add a route and a controller method and then disable CSRF and return the right headers, but I think there is a gem for that.” It sounded to me like the teacher in Charlie Brown cartoons: “Wahhh wah. Wah wahh dumbledore wahh wah.”

Still, programming is programming. Well-factored code is well-factored code. A function call is a function call, whether it executes locally or hits a web API. Any solid developer could make the switch. It took a few months before I felt mostly up to speed, but I’ve come to love modern web programming. For one thing, there are no build times. You can generally see the results of your work as fast as you can reload a web page. Since I’m incredibly impatient, that is only slightly too slow for me. Automated testing is much easier to achieve than it ever was in C++ land. And because web development is so closely associated with open source, there is a worldwide community solving problems together. I was so accustomed to needing a mental map of a proprietary million-line code base and spending hours in a debugger; it is an amazing feeling to jump on StackOverflow and be able to find a solution in minutes.

There is a part of me that feels a twinge of loss when I picture my restaurant; it is a romantic vision, expressing that creativity daily and feeding a small group of passionate customers. But, I know all too well the reality of restaurants. Ninety percent perspiration is a lowball figure. I traded that in for a situation where I can work with some of the best, most knowledgeable chefs in the world.

At ChefSteps we believe in working with “T-shaped” people. For me, the depth of the T is coding and working with a software team, and the breadth is food and writing and experience growing my own website and book. Although I usually don’t do much more than kibbitz on the actual food here, or try an occasional goofy experiment (iceberg lettuce cocktail, anyone?), my culinary experience is a huge advantage in building applications that work for both the team here and for our users.

Beyond the mechanics of code, working at a startup brings a whole different set of joys and challenges than I ever experienced in the corporate world. The entire risk/reward equation is completely different. At a big company, you mostly work on low risk, incremental improvements to grow or maintain your market and keep your customers happy. At a startup, if you aren’t betting the company, you probably aren’t taking enough risk. Because what you’ve built so far simply isn’t valuable enough to be worth protecting. It requires a very different mindset. In the early days that can cause a scary degree of pivoting, but over time you begin to converge and develop momentum as a team towards big, hairy, valuable goals.

You quickly realize that every decision you make has tremendous impact. There is no room for red tape, no room for laying back and saying “not my problem.” You are all in this together. You get mad at each other. You make up. You push each other, and find strengths you didn’t know you had. You have each other’s backs. And sometimes you all stop what you are doing and move all the furniture, because there isn’t a facilities department to call.

Working at a startup in Seattle has put me in touch with startup culture in general though, and I’ve realized it isn’t homogenous. There is a Silicon Valley-style startup culture (not limited to California) that is almost entirely focused on the “quick kill” mentality. They want to figure out something that no one else has done, market it virally, and make a quick exit. That mindset lends itself to using people. I’ve seen companies that have hired 50 programmers almost as if they hope that one of them will accidentally type Shakespeare, rather than trying to nucleate a team of a few very high-functioning engineers. The hope is those 50 engineers will get them through to the next round of VC and they can lay off the bad ones. This kind of startup isn’t built around any kind of core love for a particular product, just the thrill of money and/or power. I can’t imagine anything more boring.

At ChefSteps, we are trying to do something very different. You can see it in where we come from. Just as I came from After Effects, which has been building value since 1993, our founders, Chris and Grant, last worked on Modernist Cuisine where a team of 30+ people spent five years writing one cookbook. And you can see it in how we are funded. Gabe Newell didn’t build Valve to be a one-hit wonder, and he didn’t bet on our team to make a quick profit. ChefSteps isn’t just a business plan or a loose dream of failing fast and iterating our way to an acqui-hire; it is a philosophical experiment in allowing a group of smart, motivated people to self-organize and solve giant problems. We aren’t just a group of programmers, we are a team of cooks, writers, videographers, musicians, business people, designers, scientists, mathematicians, mechanical and electrical engineers, and maybe a stray aerodynamicist, all focused on helping every cook to cook smarter. This isn’t going to be achieved in one year or with one product, but what truly worthwhile goal is?

Michael Natkin is the CTO of ChefSteps.com.