In our First Line of Code series, Commit co-founder Beier Cai talks to prominent tech founders and tech leads building the next generation of companies, to hear experiences and lessons learned from their early days.
Ian Wong is the co-founder and CTO of Opendoor, a San Francisco-based company that is disrupting the real estate industry.
Commit co-founder Beier Cai sat down with Ian to talk about the early days of Opendoor and what it was like writing the first lines of code. Read the second post here.
Beier: Can you share with us how you got into software?
Ian: My path to software was fortuitous and circuitous. I studied electrical engineering in college and thought I was going to be an electrical engineer. Come senior year, I realized I didn’t really like the circuitry part of my studies, but I really liked the math and machine learning part of it.
So I pursued grad school and statistics. Then halfway through grad school I realized the really cool cutting-edge work was being done in industry and not in academia, so I decided to drop out. As luck would have it, I met Keith Rabois at a Quora power-user party, who eventually became my cofounder at Opendoor. And that’s how I landed my first job at Square.
Beier: Square was a pretty small startup back then as well.
Ian: The company had something like 40 employees when I started. They brought me in to do all things risk and fraud. But the funny thing was, they didn’t have enough transactions to do fraud detection. It was a blessing in disguise, because I ended up having to do a bunch of different things. That really allowed me to develop my skillset in software.
Beier: Was Square where you got your first exposure in the real world to writing fraud detection algorithms and all that stuff?
Ian: Throughout college I interned at different places and in grad school I interned at Facebook on their data science team. But the first meaningful software that I put into production was around fraud detection–the tooling that is required to build human loop style systems that we actually do a lot of today at Opendoor–or the machine learning systems that would actually predict the probability of fraud and ideally catch it the moment it’s happening.
Beier: Back then, I remember there was a lot of technology transition going on from the old-school Java to newer languages. That’s when Golang started emerging and then the Kubernetes, Mesos all started emerging. How did you choose technology for Opendoor?
Ian: That’s a really good question. I can talk a bit about our framework and how we thought about making decisions. At the end of the day, there’s a lot of judgment that’s required.
The best framework in the world is not going to substitute for sound judgment. But with that caveat out of the way, I think there are some general principles as it relates to new tech versus tried and tested. I think, first and foremost, technology is used to solve a problem, right?
You have to ask yourself, how unique is this problem? And to the extent that it’s unique, how important is it to solve the problem well? So you kind of have to segment the problem that you’re solving. What are the solutions that are going to really give your company a competitive edge vs. what are the ones that are important, but aren’t the ones that you want to put a lot of innovation energy into?
There’s a maximum which is built proprietary and by commodity. You want to identify and invest in pieces that are going to give your company a unique edge, and devote your mindshare to that and try to do things that will neutralize technical risk for the other side. I can give you a couple examples if that’s helpful.
Beier: Yes, please.
Ian: For us there are areas where we’ve got to push a boundary, like our pricing and data applications. We’re really pushing the boundaries of machine learning, especially deep learning.
Now we’re doing geospatial analytics. We’re doing econometrics. We’re doing time series. Pricing is an area that makes or breaks a company. It’s similar to Google Search, Netflix recommender, Facebook Newsfeed. And so we’re really willing to adopt and build new technology.
On the other hand, there are a lot of problems in start-ups, especially where the secret sauce isn’t in pushing the technical boundary per se, it’s actually in the ability to model a domain and handle domain complexity. That’s actually very underappreciated.
For instance, at Opendoor we are orchestrating thousands if not tens of thousands of workers to inspect the home, talk to our customers, maintain the home, make sure the home is ready for resale, service the buyer and all that. That’s a fairly complicated supply chain for us to orchestrate.
In that sense, you have a lot of technology risks, but really the key risk is how to model them well and manage complexity. You almost want to pick technology that you have a lot of shared understanding of, because you’re not really trying to say, get to a QPS falling that’s never been seen before.
Instead, you’re trying to understand how we can enable the entire organization and collaborate very effectively between engineering products and operations, so we can push the boundary in operational scaling. Again, going back to your initial prompts, it really depends on the types of problem that you’re trying to solve.
Beier: Yeah, that makes sense. You mentioned ‘QPS,’ what is that?
Ian: QPS is ‘queries per second.’ We’re not trying to push boundaries on how much volume we can pump through in an engineering system, but we are trying to optimize this really offline-online transaction at Opendoor. That requires a different type of technical sophistication.
Beier: Whenever a startup has major milestones, there’s news coverage, there’s CrunchBase and talk about the founder, the success of the business and product. But I also know through my personal experience at HootSuite that behind the scenes there are actually many technology milestones that we achieve. So I’m curious at Opendoor, what are some of the less well known major technology milestones you’ve achieved that you’re open to sharing with us?
Ian: Maybe it’s helpful to talk about what Opendoor is trying to do and then where technology fits in. At a high level, our goal is to make buying and selling a home simple and stress-free.
We’re bringing the real estate transaction into the 21st century and making the experience modern and delightful. It sounds simple but behind the scenes, there’s a lot of technology at play. I’ve always thought about the problem space at Opendoor being segmented into a few important categories. First is the consumer experience. The second is our operational platform. And the third is pricing.
If you want to sell your home, you can come to Opendoor.com and get an offer within the same day, and we’ll buy your home.
You tell us when you want to move, and we’ll purchase your home and fund you. That’s an incredible FinTech innovation, if you will. But it straddles consumer experience, operations, pricing and data. So we’ve had some pretty big milestones for each.
Starting in reverse on the pricing side, one of the breakthrough moments that we’ve had technically was this AlphaGo moment where we’re building this human loop-style system, like I mentioned to you earlier, similar to Square where it’s a purpose-built team comprised of engineers and operators who actually give customers really competitive offers, and we can do it at scale while also building a durable business.
How do we do that? It’s hiring great operators, but also building great tools and designing the feedback loops so that our algorithms continuously get better.
There was this AlphaGo moment where we realized, ‘wow, our ML algorithms are oftentimes making decisions that are at least as good if not better than house experts!’ It’s hard to actually automate some of that work, so that the human experts can do higher and higher value things. That’s one milestone we had.
Beier: I’m curious, how long did it take for the model to be trained to such a position where it’s doing either equivalent or better job than the human beings?
Ian: It takes time and investment. I don’t recall exactly the number of quarters that took. But I think the key thing is actually really purpose-building the entire stack so that your algorithms are continuously learning.
You want your system to not just be beholden to the average decision quality of an individual, you want that system to continuously be getting better in decision quality. How do you create the data assets and how do you structure the algorithm? It’s a closed loop and the systems are getting better and better.
I can mention maybe just one or two real quick other ones. I mentioned how it’s a fairly complicated supply chain that we’re trying to digitize. There was a pretty big milestone moment for us when we actually had to enter into an inventory management system completely within our kind of technology platform. Once that’s in your tech platform, then you can actually optimize different modules within that, which is really cool.
The last thing I’ll do is a quick plug for something we just launched called Opendoor Complete, which is the ability for buyers and sellers to do both buying and selling with Opendoor. We’ve actually had to take two pretty distinct sets of capabilities on the sell side and buy side and merge that in a way that is seamless to the customer.
Beier: I’m curious from a technical perspective, what’s the challenge of merging these two together? Is it business logic or integration?
Ian: It’s both. You start with, what do we want to offer to customers? We want to offer them a seamless buying and selling experience. Unfortunately, we’ve had distinct capabilities that we’ve built over time. How do you merge and integrate it so that it’s seamless to the customer? That requires asking questions like, who is the customer? How do we standardize these concepts internally? How do we standardize concepts for different buying and selling capabilities?
Like I mentioned earlier, something that’s oftentimes really underappreciated is domain modelling. Having the right semantics to describe your space is really hard. There’s a lot of hard work that goes behind that.
Beier: I’m going to switch gears a little bit to talk about building early stage teams. That’s one thing that a lot of early stage engineers care about the most. Once they get that into that VP chair, they’re like, ‘OK, let’s hire people. OK, who do we hire?’ As you know, the first few hires really are critical for the future of the company. They can define the success or failure of the company. So I’m curious, for you, what was your hiring strategy in the early days?
Ian: It’s a really important question. I think there are some general rules of thumb about this. In the early stages, you really need missionaries, not mercenaries: people who actually believe in what you’re doing in the world because inevitably there are going to be ups and downs in the company. You need people who are going to be OK with persevering.
The second thing is—this is something that I really believe in—which is, to put it bluntly, snark kills. Negativity is infectious. I think it’s very natural for human beings in general to be negative and dissatisfied. But how you express dissatisfaction is really key.
You can express it in a way that’s snarky, where you’re actually trying to get the other side to also be negative, or you can express dissatisfaction in a way that’s constructive. Like, “Hey, I noticed there’s an issue with X, how about we solve that together?” I think people who are optimists and can actually voice their dissatisfaction in a way that’s positive are really important.
Beier: I think that’s important because in a small team, it’s very easy to infect the whole team and get everybody down.
Ian: I think a related concept is a growth mindset. There’s another saying: hire for slope, not intercepts. The reality is, in a startup, everyone’s growing, and a lot of times people are drawn to startups because they’re tired of the slow, gradual growth path that some of these larger companies offer. They want it to be a really compressed learning experience. So the growth mindset actually goes hand in hand with being an optimist and believing that tomorrow, as a team, you can do a better job than today.
Another aspect of building an early stage team is, you really have to map backwards from the problems that you need to solve. So I laid out the three problems at Opendoor we knew we needed to solve: consumer, operations and pricing.
There are different types of engineers who are great at solving these different problems. There isn’t always a ‘one size fits all’ solution. I think it’s really important to be intentional about not necessarily over-specializing early, and to hire the really productive people who can actually help your company solve those key problems.
Beier: You’re talking about not just technical skills, but also someone whose mind is not fixated on a particular domain problem, but really open to solve any problem the company has?
Ian: Yeah, or with an appetite to solve the problems that the company could solve. You want folks who are not only deeply empathetic, but who understand how to deliver a great product experience to customers. On the other hand, for data and pricing, you need people who love to understand the nuances of data and how algorithms work, and how to make them better. So engineers are not fungible, there’s a skill-problem fit that is really important.
Beier: It’s not like, ‘I’m a backend engineer and she’s a backend engineer, and the two of us can change positions quickly.’ That’s not how it works, right? There are all these contexts and then a unique kind of personality factor.
Ian: As you hire an early team, you actually want to figure out who you want your anchors to be. The first team that you build, they’re going to be the ones who are hiring the next set of people. And they’re going to be the future leaders for your company. So you actually will also want to be thinking a bit about how to position certain individuals so that they can be the long term technical owners for certain work streams.
Again, judgment really matters. Generally speaking, the way to go fast is actually to get aligned, because what ends up happening is you can try and go fast on your own and cowboy some code, but then that’s going to get reworked. You’re going to have to move on to something else after you finish the sprints and someone else is going to have to take care of your code.
And so while you might feel like you’re being really productive in this one sprint, you’re going to feel the after effects very quickly. I think it’s actually really important to focus on the meta work, like how do you get alignment? How do we actually get all the disagreements out? How do I help educate one another so that we can all sing from the same hymn book?
Beier: I think it’s probably one of those things where there’s a lot of the human element in this.
Ian: It’s an important point, because it’s actually part of the job description of being a leader. Maybe that’s a part that folks might under appreciate, which is: many people who are drawn to start-ups do it because they want to be very productive. They want to move fast. And I think one challenge is recognizing that part of maturing your career is to lead. And part of leadership is to bring people along with you.
Do you want to stay up-to-date with Commit news? Subscribe to our newsletters!