Building, learning, and growing startups with Steve Corona
Interviewed by Christophe Limpalair on 12/15/2017
Steve took a year off to explore the country after his experience as Chief Architect at BigCommerce and CTO at TwitPic. During his travels, he reflected on what he learned about the growing pains of scaling a team from two engineers to 100+. Now, he's diving headfirst into cryptocurrency, adopting a new programming paradigm, and he's contemplating getting into machine learning.
Links and Resources
Hey Steve, let's just dive right in and let's talk about what you're working on nowadays.
Steve: About two years ago, I was burnt out of living in Silicon Valley. I had been planning to do this thing called a "mini-retirement," so I had been saving up for a few years. My plan was that, when I turned 30, I was going to take a year off and spend a year traveling to figure out what I wanted to do with my life. A lot of people wait until they're 65 to retire and my philosophy was, why don't I do a small retirement early on in my life?
I had turned 29, and I didn't want to wait another year to do this mini-retirement. Around that time, I left the Bay Area and spent a year traveling and kind of figuring out what I wanted to do with my time. I got into a bunch of projects and learned a lot about myself.
So you mentioned that traveling was one of your life goals. What was it about traveling that attracted you and why did you choose that as one of your life goals?
Steve: I had read a lot of books about people who lived out of a suitcase and just went with the wind, living a life that wasn't very structured. I had been living a rigid, start-up life, where you're working insane hours and putting off enjoyment for the future. Something about living out of a suitcase, doing what you want, waking up late was really appealing to me at the time. I was like, traveling is the key, and being able to see different parts of the country.
I really wanted to explore the US because I had lived on the east coast and the west coast, but I hadn't seen much in between. There are so many cities, so I got sucked into that. I took my cat with me and lived out of my suitcase in different AirBnBs a week at a time.
Out of that entire traveling experience, was there one thing that stands out as making the entire trip worth it?
Steve: Yeah, I think the coolest thing, where I think about it and I'm like, "I would do that again in a heartbeat" - and I don't think this sounds cool, but the experience was amazing - was taking an Amtrak from San Francisco to New York City. It was five days on a train. You fell asleep in a sleeper car; maybe you'd fall asleep in a city and wake up in the Rocky Mountains. You'd go to sleep again and wake up in the Plains. It was an incredible experience to see the entire country outside your window at 50MPH. Also, the people you meet on a train are from every walk of life. Some nutjobs, some super interesting people, and everything in between. That was the coolest part of the trip and the experience.
We're in your condo here in Austin, Texas, but you used to live in San Francisco. Even before that, you were in Charleston, South Carolina. Why did you pick Austin?
Steve: For me, Austin always represented this amazing culture and environment that I would travel to often for work, and I would look forward to all of those trips. It always had this very happy place in the back of my mind. I was thinking about where I wanted to settle down and put down roots after moving out of the Bay Area. The Bay Area has this sort of grime to it. It's a culture where everyone wants to do the same things, everyone's in tech, and you're just living and breathing tech 24/7. I knew I didn't want that. I wanted somewhere that was a little more expansive, with a lot of room - and there's a lot of room in Texas - somewhere where the culture was a bunch of different walks of life, more of a mixing pot. I think you have that here in Austin.
Austin is this warm, up and coming city with a lot of potential. A lot of people would tell you, if you meet natives, that Austin is full. Like, "it's full, do not move here," and I disagree. Austin is just getting started. People who live here say the city has changed a lot in the last 10 years, and I think the next 10 years are going to be likewise. I think there's a lot of potential here. The culture is really cool, the tech scene is just getting started. There are a lot of companies, a lot of cool people, it's just awesome. I love it here.
It's funny - I recently read this article that says Austin is where Silicon Valley used to be 20 years ago. Do you think that's the case? What does that mean for the culture here?
Steve: I wasn't around 20 years ago, and I wasn't in Silicon Valley in the early days. I do feel like in Austin, the things I don't like about the San Francisco culture - it's all driven on ego and VC money and this environment where there's a lot of show - I feel like Austin doesn't have that disease as much. Just as a rule of thumb, you know, I'm not saying every company in San Francisco is bad, but here they just feel more like regular businesses that have a sustainable revenue model. It's a little more difficult to raise money here and I think that's a forcing function where the companies have to be a little bit less like these crazy tech startups you read about, and more like Fortune 500 style companies.
I think the word I would use is "sustainable," to describe the tech culture here. That kind of seems like the opposite of what I would imagine the Bay Area was like 20 years ago. I imagine that being money as gasoline being poured on a fire. I don't see that as much here. The culture here, long term, ends up being more healthy, more sustainable, and more enjoyable for the people that are working in those companies.
You mentioned that, in addition to traveling, you also poured a lot of time into various projects. What are some of those projects you've been working on?
Steve: I really got into different new tech. I had a whole laundry list of tech I wanted to learn. The way I learn things is by building stuff, doing stuff, getting my hands dirty with it. So I was looking at different tech like machine learning, Elixir, there's a lot of stuff on the cloud that I had seen and wanted to mess around with, but hadn't had a good opportunity. I started building weird little apps and things for Raspberry Pis.
One day, I just got into cryptocurrency - I was like, "Oh, there's that Bitcoin thing." I had bought some stuff online with Bitcoin, and that's all I had known about cryptocurrency, but I had started learning more about it and got really into it. I just went down this rabbit hole building tools and programs to help my day-to-day, using all the new technology that I wanted to get my hands dirty with. Like Elixir, Docker, all the new AWS tools, Kubernetes, and all this stuff. I got into that because I found that project that drove my ability to sink my teeth into something and start playing with all the technology that I wanted to.
What is it about cryptocurrencies that grabbed your attention? Why did you want to spend so much time with it?
Steve: Cryptocurrency is this idea of distributed trust, or a distributed ledger, where you can use it as a payment system because you can trust the ledger everyone keeps is honest. You're not saying that you have a certain amount of coins when you actually don't. Because of the way the math works out, you can trust that if you show me on the blockchain that you sent me Bitcoins, I can trust that you actually did that and you're not going to spend them somewhere else.
I will say that I'm not the world's biggest Bitcoin expert or cryptocurrency expert. But it's really interesting. A lot of people will say it's like the Dutch tulip bubble, where tulips went to these crazy prices. And Bitcoin is just one. There are many cryptocurrencies - there are other currencies and other coins that have prices from tenths of a cent all the way up to hundreds of dollars per coin. When you think of crypto, you think of Bitcoin, and it's really just the beta of what blockchain and cryptocurrency can be. This is our first go at it - there are problems and it kind of sucks, there's a lot of manipulation - but the fundamental blockchain is really interesting.
A lot of banks are starting to look at ways to facilitate things. Maybe Bank A wants to move money to Bank B - right now they use ACH (Automated Clearing House), but maybe blockchain can replace that. Or I've heard about shipping companies that use blockchain to track where their shipping containers are in the world, and being able to update this ledger of containers in a distributed fashion. The underlying technology is really cool.
So, what caught my attention with cryptocurrency and Bitcoin is that you can trade it like a stock. There's a whole system of exchanges where you can buy and sell. Like you can buy a share of Apple for a certain price and, later, sell it for a certain price. And you can do that with the coins. I had never really done any trading on the stock market in the past, so I looked at this and I was kind of blown away. There are millions of transactions happening in a matter of minutes. It's this large scale problem, there's all this data, all these algorithms, there are people that are trading, there are bots that are trading, and it's just so cool. All of these exchanges have open APIs. I thought it would be cool to pull in all that data and do something with it. It's a high scale problem - there's all that data and that's kind of exciting, and then maybe you can build an algorithm and do something with trading.
It was not like, "I'm interested because I'm going to solve a problem and save the world." I think that trading coins actually provides no value to the world. It was more like this was a cool and fun thing to work on, that gives you exposure to a lot of technology and a lot of different problems, which gets me excited. Even though maybe I build tools and stuff for the blockchain, I lose money doing it. But it's such a fun, tough problem to crack and it pushes all those buttons in my head that makes me interested.
Tell me more about those problems you're trying to solve and what kinds of tools you're building. I know you mentioned trying to gather and filter a lot of that data. How do you even get started?
Steve: The most difficult problem is that there's a lot of data ingestion. If you want to collect every trade that happens on every platform, you're talking about a stream that's hundreds of megabytes per minute of data coming in. If you want to do it right, you need to ingest all that, process it, make some decision on it, and store it somewhere.
So there's this comic with a big semi truck with a little Tonka truck strapped to the back bed, and that's the only thing it's carrying, and it says "When you run WordPress on Kubernetes." I felt like, in some ways, I wanted to do that. I built this big Kubernetes setup on AWS with all the new, shiny technology. The thing I've spent most of my time on is the data ingestion engine, which is in Elixir, which was a new language for me. I was using all the new things that I haven't used yet.
So I built this massive data ingestion pipeline. All these exchanges have their own APIs - some of them use WebSockets, some of them use this weird WebSocket thing I've never heard of by Microsoft, like a spin on it, so you need to write a client library. And then pulling in all this data and doing it in a way where your program can scale and be distributed across multiple containers in your cluster, then taking that data and storing it somewhere and putting it in a queue so you can use other programs to act on it. So I've built this pipeline to suck in all this data from all these exchanges. It's fun because it's such high scale - you're talking about millions, tens of millions of data points coming in per day, and making sense of that.
(Doesn't this look like a scene from the show Narcos?)
You said one of the reasons you wanted to use Elixir for this project was because you had never used it in the past. Was there any other reason why you wanted to do that? I can see a lot of value in that kind of language, but was there a specific reason that drove you to use Elixir?
Steve: Elixir is one of those new, hot technologies that a lot of people are talking about. I have a background in Ruby on Rails as my framework and language. So Elixir, and a framework called Phoenix, caught my eye as a faster replacement for Ruby on Rails. It's on the Erlang VM, which is this virtual machine made by one of the big phone companies that runs a lot of their phone infrastructure. It's made for high concurrency and high availability. It can do a lot of interesting paradigms that you don't see.
You look at it on the website and say, "Wow, this is just like Ruby, but faster." Then you dive in and you learn it's nothing like Ruby. It looks like Ruby, but the syntax is totally functional, there's no objects. It has a lot of these new paradigms in programming that you're not used to seeing. A lot of people will get mad and be like, "The thing you're going to talk about, Steve, Smalltalk had that 20 years ago." But my background is C and PHP and these declarative languages, so I've never seen these paradigms.
Elixir doesn't really have variables in the true sense. All the data is immutable, so you can bind data to a name, but it's not a variable in the sense that you think about a variable. You can do this weird pattern matching stuff and you use it and you're like, "My mind is blown, I didn't even know that was something you can do!"
For example, in Java, you may have a function and you can overload it. Like you might have "add" and "add" can take an integer and then you can have an overloaded version where it takes a string, and different implementations. When you call "add," it's matching it based on the type, and that's how it decides which implementation to use. In Elixir, you can match not only on type, but on that value of that data. So instead of taking a variable name where it's just a type, you can say the only way you match is if you call a string called "Steve." You can have a different function implementation for a bunch of different strings. You can match within arrays and within maps, and it's this weird paradigm and it's very powerful.
The other thing you can do, when a program is running, is load in your new code without shutting the program down. All the current threads - or actors, as they're called in Elixir - will run the current implementation, and all the new ones that start will use your new implementation. So it has this high availability aspect where you can push new code without ever shutting down the program, it's just doing hot reloads.
I got really into it. You learn all these new paradigms and your first reaction is, "Wow, this is just like ruby but it's really fast." Your second reaction is, "Holy crap, this is totally different." Your third reaction is, "I hate this. I want to do this thing that would be really simple in another language but it's really difficult in Elixir." And then you get over that hump where you hate it because it's so different, and you fall in love with it. It's a very elegant way to design distributed systems, and it just so happened that it was the perfect tool for building this highly available, highly concurrent data pipeline. But I did not do that on purpose. It just happened to be the right tool for the job.
I can see a lot of value in playing around with different technologies like that. Maybe not new, like cutting edge, but newer, established technologies that are helping different companies. The problem with that is, how do you find the time to learn how these technologies work or what benefits they have? Especially when you're working your day-to-day job. You might have deadlines, you might be stressed out, how do you make the time to play with these technologies and see if they're a good fit for what you're doing?
Steve: The first thing I'd say is, the only way I can learn a technology and really know it, is to build something with it. I have to find a project that gets me excited. My mind is where I'm either intensely focused on something or totally apathetic and disinterested. So I have to find that thing where I can really focus on it and dive in. I get that feeling and just know, then I can look at what's on that technology back burner that I want to learn. The enthusiasm of the project will keep me pushing, even though I may get frustrated when I'm, say, learning Docker for the first time. You're just pulling your hair out and saying it's much easier to not use it. But you push through that until you start to see the benefits and get into a productive workflow. Finding that project is what gives me the motivation to push through and learn something.
As for finding the time, what I did when I was in San Francisco, was the concept of an "artist day" or an "artist appointment" for yourself. Say, every Sunday between 2PM and 6PM, that's my time to sit down and work on a project or learn something or do something creative. I think that when you do that, and you have that schedule, it creates this forcing function where you actually do it. If you just say, "I'm going to do that sometime this week," you're never gonna do it. You never find the time. You have to make the time. When I lived in San Francisco, I did that all day Sunday. Sunday was my focus day and I had a routine where I'd walk to the store and buy some prepared food so I wouldn't have to cook or be distracted. I'd buy a kombucha, that was just part of my routine, and I'd try to keep that schedule and not mess it up. Because it was scheduled, I did it.
As far as determining the technologies that are worth investing your time in, I think the biggest way I identify those is I wait until I see some momentum. I read a lot of Hacker News and programming subreddits. I read about everything that's coming out. So I might read about Elixir, I'll give it a glance, spend 10-20 minutes and say, "Okay, now I can talk about it but I've never used it." I'll do that with new technologies, and when I see it keep popping up and I keep hearing about it, or how so-and-so company is using Elixir, I think "Okay, maybe I want to give that a shot." But I never jump in and be the first one to use a language or new tool. There's so many of them that if you do that, you'll spread yourself so thin that you'll never learn any of them.
You have a really good example of this in your own life and career with TwitPic. At the time you joined, the application had a lot of users coming in, so the application or infrastructure may not have been able to handle that load. And the CEO and founder may not have had that expertise to help with it. So you came on board and helped fix it. How do you learn things on the fly, when things are breaking and you have to fix it?
Steve: You said the founder and CEO didn't have the technical expertise, but honestly, neither of us did. I was fresh out of getting kicked out of college. I was laid off at my job before with an ad company. I had no idea what I was doing, things kept breaking even while I was there. Things I tried at the time, even things I thought were a good idea, would break - looking back, I see that actually wasn't a good idea. It was that learning on the job experience, it was making a lot of mistakes, it was pouring my entire waking hours. I would wake up, sit down and start coding, and I wouldn't get off the computer until I went to bed.
The thing I learned is that at a certain point in a company, whether technical or culture or hiring, the thing you do at 5 people doesn't work at 10 people, and that doesn't work at 20 people... So you have to keep evolving. The things you used to do, at a different size may be the worst thing you can do. You have to know that you're always going to be evolving, tech and culture-wise. You have to be open-minded enough to know that you're going to make bad decisions and have to redo things many times over as you grow. Learning hands-on that way gave me a good perspective of how you can keep building, and how you can go from 10 people to 1000 people. You look at these companies at scale and think it's a linear pattern, but it's really an up and down pattern as you change things every step of the way.
What advice would you give to a manager who hasn't been in this position before and now they have a team of engineers? As they grow that team, a lot of the communication breaks down an a lot of the processes that worked for employee number 5 don't work for employee number 10. What advice would you give them to be able to structure that, create the right processes, and continue to scale that as the team scales?
Steve: A good friend of mine says that engineering is a people problem. The hardest part of growing an engineering team and being productive and scaling at a certain size is managing the teams, managing the people, keeping everyone happy, keeping the way people work productive and healthy. And I agree with that. One of the hardest parts when you're starting off on the march from one person - you're the only person writing code, you know the product, you're building everything - to ten people is that the way you communicate changes dramatically with every new person on the team.
When you're one person, you know everything, you don't have to communicate with anyone. When you're two people, now you have someone else, but you can just say, "Hey, this is what I'm thinking," and they say, "Cool." You're not documenting anything, it's just one-to-one communication. When you have three people, now maybe I tell you something but I forgot to tell the other person, and you start to have "lossy-ness" with the way the team communicates. Then that grows exponentially - I think a lot of teams get stuck with that early on. The founders that were there, the early people, have built all this stuff and they're trying to control everything, and learning to delegate is hard.
The way you build the team and structure the teams, every person is going to change that dramatically. Maybe you start off and you're just shouting across an office. Then you move to Slack. Then you move to Jira and it happens really fast in the beginning, and you don't want to overburden it by being too heavy on process in the beginning. That's another thing that can really hurt a startup: you have five people and you overburden yourself with process so that you get nothing done. You can lose that advantage of being a startup, where you can move fast because you don't have that much process.
You mentioned that delegation is super hard, and this is something a lot of people struggle with, especially first-time managers. What advice do you have to give them that can help them delegate to their engineers and offload a lot of the workload they have?
Steve: The most difficult part of delegation, especially as a founder, is lack of trust. That's what I think causes a lot of problems as a founder - you want to trust the team you've hired, but it's hard to let go. And it's unfounded, it's lack of trust because you're scared. It's your own ego that you're struggling with. I think if you can recognize that and look at it logically and introspectively, and say, "The reason I'm having trouble letting you do this work is because I'm afraid that it's not going to be as good as what I could do." It's not because that person is a bad engineer, but because I'm the founder and I know everything about this product.
The only way you overcome that and let the team succeed is by allowing your team to have your entire trust. You have to say, here's a product or feature, I want you to take it and run with it. And that empowers people. Of course, you advise along the way, but not be overburdening. The way your team grows is because you've empowered them and they've been able to take these problems and solve them. It may not be the optimal or best way in the beginning, and that's okay. Not everything needs to be solved in the best way, it just needs to be solved. Giving them that experience and allowing them to grow gives them confidence. Also, as the person delegating, it gives you more confidence in the things they build in the future. It all starts internally, as the person delegating. You're not the only one that can be good at it.
At TwitPic, you had a smaller team. It was a younger platform. But when you moved over as Chief Architect at BigCommerce, that was a more established company and team. What was that transition like?
Steve: It was really difficult at first. Coming from TwitPic, I came from a handful of engineers. They were all my friends, they were people that I hung out with on the weekends, so it was more like a family and people that I would hang out with even if I wasn't working with them. We were a really productive, really small team, and I loved that. Moving to a big company, I will say I made so many mistakes because I had the same mindset. I didn't realize that at hundreds of people, there's all these people communication problems and things you have to think about. The things I did at TwitPic didn't necessarily translate to working at a larger company.
One of the mistakes I made when I came in was, I would say, "We're going to do blah blah blah, and we're going to use this technology." At a small company, that works. You can just hash it out. At a big company, you're just dictating what you're going to use, and that's actually a way to build bad communication. That's something I struggled with early on - I knew that we were going to do this - but just dictating it, not explaining why, and communicating in a way that's not just sitting down with a couple engineers and explaining it, but putting it in a way that can be consumed by hundreds of people in the company. You have to let them come to their own conclusion of why we should use a certain technology.
That was the hardest thing for me, transitioning to a larger company. The way you interact with teams is totally different. There's still only one of you, but there are so many people listening, and the things you say have a large impact on their day-to-day job. If someone is frustrated or they disagree with you, they don't have a great outlet to disagree with you. Whereas, with a team of five people, they can just speak up and say, "Hey, I think that's a bad idea, here's why." When there's this massive team, maybe there's a layer of management between you and them, it can be really annoying for them to just have you dictate what we're going to use. I think, for me, I needed to become a better communicator and I didn't do a good job in the beginning.
That's really awesome advice, Steve, thank you. Can you tell us a little bit more about your own day-to-day life at BigCommerce? What was it like, what did you work on, what did you do?
Steve: My role there was chief architect, so I had a team of architects that I worked really closely with. Software architect means so many different things at different companies. I kind of hate the term a little bit because I think it has this connotation that an architect is better than an engineer, which is not the case. My day-to-day at BigCommerce was figuring out what the technical strategy was for the software, how we were going to build things with what technologies, how that evolves, how we take the technology we have right now and where we want to go, and bridge that gap. With big software companies, you can't do something like, "Hey, we're going to rewrite the app!" You can't do that, but you want to evolve the technology and change things. Maybe choices that you made or previous employees made in the past didn't scale with the way we're using the software now, or with the way the company is going. You have to look at that technology and come up with a strategy of how you get from A to B.
One of the things we were doing at BigCommerce was - it was a monolithic PHP application with about 1.5 or 2 million lines of code. We had enough people where it made sense to split that application up into microservices, so a lot of my day-to-day was spent with teams figuring out what parts of the app become a microservice, what are the different domains. It was a shopping cart app, so what are the different services? How do we, over time and without any downtime or changing the way the product behaves or introducing any bugs, extract functionality from the monolithic app? Maybe it's building it in a different language, maybe keep it in PHP, but how do we exract that and put on a clean, RESTful API or something, and create a service that's standalone and outside of the monolithic app. My day-to-day was just working with people and talking through - how is that split up, how is that broken out of that monolithic application.
I mentioned in the intro that you're advising startups. What led you to advising and what attracts you to that?
Steve: I had advise a couple companies that have really interesting problems, or companies where I really like the founders. I think that they're going to be successful - whether it's this company or the next one. I see that drive in them that I admire. I think where I see a lot of companies, especially early stage startups, which I really enjoy, where they struggle, is... Okay, I see this mistake a lot: they look for a CTO and they'll find someone who looks great on paper, has worked at some big software companies, they were managers. They'll say, "This person looks great. They have all the experience, they want to get into an early stage startup." They bring in people to run their engineering team, but that person has never had a startup background, and they get lost. They want to take that culture they know from the big company, where there are layers of tools and time-tracking, where just to do five minutes of work, there's 45 minutes of data entry and logging to track it. They bring that kind of culture in way early in the company.
Your biggest advantage as a startup is that you don't have as much process. You can tap me on the shoulder and say, "Hey Steve, there's this weird bug, check this out," and I'll say, "Oh yeah, you're right, I know what's causing it." You type up some code, push deploy, and 20 minutes later we've fixed that problem. For a lot of people who don't come from a startup background or don't know that world, that's scary. We didn't track, we didn't log that bug, it's not in Jira, there's no papertrail. And that stuff is important, but if you bring it on too early, it can really put molasses in your engineering team. And that's what I see a lot of.
My advice to startups, especially on the engineering side, is practice good "software development hygiene," but take advantage of what you have as a team. Your bigger competitor with 100 employees doesn't have that advantage. They can't take code and ship it 20 minutes later. That's not good practice for a huge team, but it's really empowering when you're small and it gives you a huge leg up to be able to ship fast and try new things. You have a small team and you all can get in a room and talk about it real quick, say, "Yeah, let's do it," and that's all the decision making that needs to happen. So that's my advice for startups. That's what I tell the companies I advise, and I help them to not make that mistake.
All right, last question. When are you writing your new book?
Steve: I know nothing about machine learning. Nothing about it. But I know that it's important and that a lot of people want to learn it, so what I've been thinking about is a problem that I want to solve involves machine learning. What I think would be really cool, and I think this is a course or a book that I want to produce, is it will be my journal of solving that problem with machine learning, while I'm learning it. So chapter one would be like, "What the hell is machine learning? This is what I think machine learning is." Then I'd go back and update it once I actually know more about it. Let's say I was completely wrong, like I thought machine learning was XYZ and it's actually this whole other thing."
I'd like to do something like that, where it's a journal of me solving a real problem with machine learning, as I'm learning it. I think that would be really valuable for people who are in the same boat as me, who would like to learn it, don't know where to start, and want something practical and hands-on that they can follow along with. They don't necessarily need to know the nitty-gritty manual details. They just want to know, "I have a problem, how do I solve it with this technology?" So that's what I'm thinking, but no promises that I'll actually do that.
Steve, thank you so much, I really appreciate your time. If people want to follow up with you or keep track of those projects you're working on, how do you recommend they do that?
How did this interview help you?
If you learned anything from this interview, please thank our guest for their time.
Oh, and help your followers learn by clicking the Tweet button below :)