Lessons from Erik Bernhardsson, founder and CEO of Modal

On Startups and Business

On the nature of startups: "I used to love tinkering with hard problems, and still do – but spending 7 years at Spotify, I realized that I actually love being part of a startup journey even more." [1]
On finding a niche: "Don't be afraid of going into a weird industry. No one thought the music industry seemed like a great place when I joined Spotify 2008. I bet people said the same thing about taxi industry in 2011. Etc. Things always look cool in hindsight." [2]
On the importance of a commercial mindset: "I think any successful project has to be built with a super commercial mindset. No one cares about whether you can get z% accuracy in your churn prediction model. Can you use the the model to give decision makers insights into how to reduce churn?" [1]
On building incrementally: "Solve for the business need first and make sure you're building something that is valuable for the business. Then build something super incrementally. Start with a prototype that's end to end that uses the most simple model you can think of that's still enough to show some potential." [1]
On the value of plumbing: "I think almost every time when I've solved these plumbing things, I wish I would've just solved them a year earlier. And I'm a very data driven person. I'm like, 'We should get all the data into the data warehouse as early as possible.' But even for me, I'm regretting all these times when I didn't do that." [3]
On the danger of tool-oriented hires in startups: "At a startup that might be very, very dangerous to hire a person like that, because they might everything needs machine learning. That's not true. 10% of things need machine learning. So what I want to hire is the people who maybe they know machine learning, but for them it's just the tool in the toolbox, and the real goal is to figure out what the business need and build those things." [3]
On the evolution of his startup, Modal: “I quit my job during the pandemic… I started thinking a lot about the data, AI, and machine learning space. It's always been frustrating to work with from an infrastructure point of view. I thought I'd just build a better version of Luigi… but then realized, to get workflow scheduling right, you have to nail code execution first.” [4]
On early-stage focus: “I think it's good to listen to customers, but in the first year, we didn't. We had a strong point of view about the infrastructure the world lacked, shaped by my decade of experience.” [4]
On long-term vision: “2025 goals include 3-5x revenue growth, expanding into enterprise segments, and building for new use cases like distributed training. We aim to materialize the vision of an end-to-end platform for machine learning development.” [4]

On Machine Learning and Data Science

On the reality of machine learning's role: "Rarely is machine learning the fundamental enabler of a product. It's often an enhancer." [5]
On when to apply machine learning: "Most machine learning is sprinkles on the top. The first few years of product iteration is about getting the 'tablestakes' out of the way. The ROI of those are just vastly bigger." [5]
On the commoditization of ML: "Machine learning can be a first mover advantage. But there's a high likelihood whatever insight you have will be independently discovered and published at the next NIPS/KDD/ICML." [5]
On the two camps of data science: "There's two camps, one is the 'business insights' side, one is the 'production ML engineer' side." [6]
For the 'business insights' camp: "If you want to understand the business and generate actionable insights, then in my experience you need pretty much no knowledge of statistics and machine learning... It really just boils down to doing lots of highly informed A/B tests. And above all, having deep empathy for user behavior." [6]
For the 'production ML engineer' camp: "In my experience understanding backend development is super important... I've seen companies where there's a 'ML research team' and a 'implementation team' and there's a 'throw it over the fence' attitude, but it doesn't work. Iteration cycles get 100x larger and incentives just get misaligned." [6]
On the importance of statistics: "Seriously, I really wish I had studied more of it in school. Basically goes for anyone in the STEM field, IMO." [2]
On separating ML research and implementation: "I don't understand why you would deliberately do this – all the iteration speed goes out the window." [1]
On the danger of isolated ML teams: "I've also seen issues where ML teams are their own isolated teams that are coming up with solutions no one asked for... It's much better in that case to have ML practitioners embedded into teams and work as a part of that team's prioritization." [1]
On the evolution of data problems: "It feels like data is like where front end and back end was like 10 years ago. People still kind of trying to figure out like best practices like how do we write code like how do we test it how do we deploy things like no one knows." [7]
On the future of data engineering: "Data engineering is funny because in a way, I kind of don't want it to exist. My prediction has always been it's going to go away at some point." [8]
On the true job of a data professional: "I don't really like the idea of it being someone's job to shuffle data around. I want everyone to think about what the business needs and to build business applications." [8]
On his motivation for building data tools: "I'm working on a set of amazing tools and infra for data teams." [9]

On Developer Productivity and Tooling

On the importance of developer experience: "So much of developer experience comes from having like a super fast feedback loop where you can like take code and execute it in the cloud in a way where almost feels like it's local." [10]
On the cost of poor developer experience: "The cost of poor developer experience is real." [11]
On the future of developer tools: "If there's any persistent lesson we've learned about the future, it's that it's a lot harder to predict than we think. But I think it's a pretty safe bet that software engineers will have some amazing tools in 2030 that makes today's tool feel antiquated." [11]
On what should be outsourced: "Pretty much everything that isn't core business logic should rationally be pulled out of your codebase and sold back to you at a fraction of the cost." [11]
On the problem with many data tools: "I think to what extent data teams are wasting so much time on infrastructure stuff, stuff that's not core business logic. So if there's any tool I want to call out, maybe as 'bad', it would be maybe Kubernetes... I just want to do data. Why do I have to write YAML files?" [12]
On the value of self-sufficiency: "Are you able to deliver business value by building something across the whole stack, without having to rely on other peoples/teams to help you. If you can do this, you can iterate much quicker." [2]
On the growth of developer-focused products: "As the cost of building software goes down, that drives up the demand for software engineers. That then drives up the demand for even more products built for software engineers. That then drives down the cost of building software even more! This flywheel seems like an excellent thing for our economy." [11]
On the evolution of developer productivity: "Developers have been getting like probably 10x more productive every decade for the last four decades or something that was kind of crazy like on an exponential scale we're talking about 10,000x improvement in developer productivity." [13]
On the gap between local and cloud development: "If you get rid of that like distinction between local and and cloud and just turn it into like one environment you just run things in the cloud you solve a lot of different problems but in order to do that you have to make it fast you almost you have to make it feel like you're developing locally when you're running things in the cloud." [10]
On his approach with Modal: "We threw out Kubernetes out the window we threw out Docker out the window. we built our own file system in order to optimize for how container images are distributed we built our own scheduler." [10]

On Career and Learning

On continuous learning: "When you're no longer learning, then it's time to do something else." [2]
On working with smart people: "When I say smart, I really mean people you can learn from. I've worked with some very smart people who I didn't learn from and it was a waste of time." [2]
On motivation: "It's unclear if I really want to learn Clojure or just want to have learned Clojure?" [14]
On the value of side projects: "It's also OK to go home after work and stay up until 1am hacking on a side project. This could be a wonderful thing if you enjoy it and are learning things." [2]
On showcasing your work: "I really think showcasing cool stuff on Github and helping out other projects is a great way to learn and also to demonstrate market validation of your code." [6]
On achieving expertise: "Seriously, I think everyone can kick ass at almost anything as long as you spend a ridiculous amount of time on it." [6]
On the importance of a physics background: "But coming from a Physics background, I always loved math, and it felt like one way I could solve 'hard' problems that maybe other programmers would not be able to." [1]
On his early career at Spotify: "I managed to convince Spotify to hire me in 2008 to build a music recommendation system despite not having much experience with ML. This was before deep learning, and machine learning was a bit more 'underground', which meant that I had to build pretty much everything from scratch, so I think being a coder at heart was very helpful." [1]

On Hiring and Management

On what he looks for in hires: "The most important thing I look for is curiousity about business and product—an entrepreneurial drive that compels you to dig into numbers and understand how everything fits together." [15]
On the problem with interviewing: "Interviewing is a noisy prediction problem. When I started recruiting, I had so much confidence in my ability to assess people. Let me just throw a couple of algorithm questions at a candidate and then I'll tell you if they are good or not!" [16]
On exploding offers: "Exploding offers are bullshit. I do a lot of recruiting and have given maybe 50 offers in my career. Although many companies do, I never put a deadline on any of them." [16]
On paying for talent: "When I started building up a tech team for Better, I made a very conscious decision to pay at the high end to get people. I thought this made more sense: they cost a bit more money to hire, but output usually more than compensates for it." [16]
On the importance of decentralization: "Every company should think about how to realign how they build technology to focus on decentralization and higher iteration speed, embedding engineers throughout the factory." [17]
On the fallacy of no-code/low-code replacing engineers: "In the long run, it won't be a good idea for companies to adopt tools with the only purpose of building technology without engineers." [17]
On the demand for software engineers: "What previously used to take 1,000 hours now takes 100 hours. If demand was fixed, it would mean mass unemployment and lower salaries for engineers, but demand isn't fixed! As I've implied earlier, lower costs of building software means new opportunities open up." [17]
On the productivity inequality between companies: "A failure to realign the factory means lower iteration speed. A lack of engineers means a temptation to adopt tools to build technology without using engineers, with associated costs that are much larger." [17]

Learn more:

Lessons from Erik Bernhardsson, founder and CEO of Modal

On Startups and Business

On Machine Learning and Data Science

On Developer Productivity and Tooling

On Career and Learning

On Hiring and Management

Written by Antoine Buteau

Lessons from Jade Rubick

Lessons from Lulu Cheng Meservey