Hi folks! I’m Jon.
I lead engineering at Streamlit, acquired by Snowflake in March 2022. Before Streamlit, I spent 7 years at Heroku (Salesforce), where I helped build various engineering teams, primarily those responsible for the underlying runtime, logging, routing, and orchestration platform that powers the Heroku product. I live in Charlotte, NC with my partner, Mai, and our 8-year-old daughter, Ella. In my free time, I’m trying to learn to be decent in golf, which has led me to build a mini simulator on my back porch (spoiler alert: I’m still no good 😅).
Happy to answer any questions or be a resource for anyone here. Ask me anything!
Top comments (21)
How much of the engineering team at Streamlit was hired from the open-source community?
Did you use the fact that Streamlit is open-source to create an interview exercise to hiring candidates?
Thanks in advance,
Directly from the Streamlit community, maybe a handful. Folks who have contributed to open-source before? A ton! In fact, it’s a main source of attraction and interest in working with us.
We considered making it a part of our interview process, but it can be a bit of context build in order to effectively make contributions. Instead, we focused on similar problem areas that had self-contained context.
Makes a ton of sense.
Hi Jon, congratulations to the team and you on the acquisition.
My question is two-fold. Could you please shed some light on your early go-to-market strategy and how your developer experience evolved with the product. Especially any lessons on what worked and didn't work would be helpful.
The story is probably not going to be surprising and will sound cliche. As I understand it, we scratched our own itch with the open source python library, and then we talked to our users, especially the ones using streamlit at work. One of the questions that was coming up the most was “we don’t want to have to run this thing ourselves, can’t you do it?” — so we did.
Over time, what we found is that data scientists were huge fans of our tool, and were pleading with their managers to pay for our service. Then came all the hurdles you can imagine when going through a purchasing process at a company - security, risk management, pricing. I would advise not underestimating security as a hurdle to adoption, and would recommend prioritizing work that makes your product something that security teams will want say “yes” to.
Thanks Jon, that isn't cliche at all. Solving an unmet need and listening to customers, love it!
You bring up a great point about the hurdles to get enterprise-ready and prioritizing security, thanks.
Hello Jon, Kudos to your team!
What are the better ways for increasing adoption and discoverability of an Open Source project from your point-of-view.
Also What were the key strategies that helped streamlit in scaling the journey?
To be totally honest, I joined Streamlit when it was already popular in the data science community. Our founders were smart folks solving a problem they had previously experienced, that it turns out a lot of other people were struggling with as well. I think what Streamlit got right was engaging with the community very well, and prioritizing that from the start by staffing it directly.
Re scaling, at least in terms of people, I think the two key elements were that we established an attractive culture, and the success of the product was externally visible. When we interviewed people, we were very honest and transparent about who we were, and I think people really appreciated that. We have a very human culture that shined in those conversations, and folks we’ve hired told us that they were sold based on the conversations they had with members of the team. I think our external success indicators gave people the confidence to take the leap from there.
Thank you, that makes a lot of sense to me.
Key point: If you want to create, express, and distribute value, you must begin with yourself and the team.
Hey Jon! Thanks so much for doing this.
What are some tips you can share for founders or other engineering leaders building open source startups around how to manage development teams that may split their time between open source project maintenance / contribution and also commercial product development / eng? Should these teams be distinct, or the same, or a mix? Any thoughts on these lines would be valuable. 🙌🏼
There surely can’t be a one-size-fits-all answer to this.
When it comes to organizational models, there are a lot of organizational models out there, and none of them ever feel perfect, or even good. It’s possible that team structure is not the thing that is going to be the secret sauce for a company. Doing the right things, doing them well, building a fun culture that attracts great people, those seem to be what matters most.
One of the strongest principles I’ve held onto is not creating unnecessary distraction for teams. I’d recommend not re-orging frequently; optimize for keeping the same groups of people together, provided they enjoy working together. If you must, change projects instead: for example, ask the open source team to work on a commercial thing if it’s important enough to the business.
Super useful insights. Thanks Jon!
Hey Jon! Thank you so much for doing this. Could you speak to developing the open core business model, and how you worked with the founders to set expectations and execute with the engineering teams?
Hi Liana, happy to be here!
I can’t say for certain what compelled the founders to choose this business model, but in my experience when you start something as a side project to scratch an itch, it feels like a default choice as an engineer to start with something open source, so that others can benefit. Incidentally, it turns out it’s a great way to initially build a community around a project and grow it organically both in terms of its capabilities as well as its usage.
I don’t think it was much different from how you’d do this in any other instance. Set meaningful and ambitious goals, iterate and test hypotheses. A slightly controversial perspective I might hold is to not focus so much on whether you hit a goal you set some time ago, but whether or not you had the impact you’d hoped for. Sometimes the goals you set at the beginning of a quarter lose relevance shortly after you start building or get customer feedback!
Awesome - thanks for the answer and insight!
What was it like getting acquired?
That’s a big question! I would say the most prominent feelings were fear and excitement. Since excitement is the fun part and easy to handle, I’ll talk a bit about how we handled the fear.
We fielded a lot of questions from the team. What does this mean for our culture? Will I even be a part of the new company? Will we get to keep working on the same things? In our case, this was a positive and friendly acquisition for all involved. Snowflake is actually a pretty remarkable place and there was already so much alignment between our teams. I think that’s probably a good selection factor when considering being acquired: do you feel like the company cultures will fit together well? With that in hand, largely it was just about having honest conversations and introducing people!
Wow, Streamlit is incredibly cool.
I'm curious what the most valuable customer use cases have been so far, and also what are the coolest use cases as well?
Thank you! There were a lot of amazing people involved, and well before I got here.
Turns out we showcase the coolest use cases already in the gallery on our website, streamlit.io/gallery :)
As for the most valuable, that’s an interesting question. I think Streamlit shines when you have some data you want to understand very quickly, and collaborate with someone else on. That’s where it’s most valuable to me.
For companies, I imagine it’s very similar. Companies use Streamlit to get better understanding of data and share those insights with their colleagues in interesting and interactive ways. We use Streamlit at Streamlit, too! We have internal dashboards that help us understand data and make better decisions about how to improve the product itself.
What do you consider your core expertise as an engineer?
I don’t get to write a lot of code anymore, sadly! When I was coding regularly, I liked to think I was great at writing very clean and understandable code. I avoided complexity, worked hard to separate concerns and make things as readable, simple, and flexible as possible. I think this obsession with the communication elements of writing code led me to finding similar problems in the engineering management world.