Three months I unexpectedly received the opportunity to join Dolthub, a seed stage startup with <10 people, as a software engineer. I wanted to take a step back and reflect on what I’ve learned so far about joining a startup both as an employee and as an engineer in particular.
One of things that interested me in joining a super early startup was the idea of wearing lots of hats. That is, the opportunity to try different roles and work on all sorts of business units. I imagined myself being able to do 3 things: coding the actual product, conducting customer research, and identifying new growth opportunities. What I quickly realized is that each of these actions themselves represented 3 highly intense roles. Just like shipping high-quality code is super hard, so is sourcing great customers or sketching the right product to build.
You may ask yourself: “Shouldn’t I just push through all of this hard work?” When you factor in context switching between these disparate job functions, I think the result is only going to be a mediocre output. (Prove me wrong if otherwise!) I do want to point out that I’m not arguing for separating yourself completely from other teams. In fact, I think engineers should 100% take the time to think about the product they are building. But what’s more important is establishing your legitimacy as an expert in your job domain and producing the value you were hired to create. Focus on your craft.
When deciding to join Dolthub, I found myself enamored by the vision of our database becoming the data format for data collaboration. Within 2 months, I was surprised to find that our primary focus shifted to selling Dolt as an application level database. Turns out it was getting much more difficult to incubate our marketplace while we were getting real traction delivering our database as an enterprise tool. What I now realize is that vision is great when evaluating a company but never forget that the market is the boss. In fact, I would never recommend joining a startup with vision as your #1 factor (maybe there’s exceptions in deep-tech). Things can change at anytime.
When I joined the company I had a lot of different ideas on what features we could build or who we could sell the product too. What I quickly realized is that my ideas were “cool” but not high leverage. I think in a company of our stage, the question you need to ask when considering a new feature is: “Does this tangibly get us 10 more customers?” This definitely includes engineering as well. Developers hours are super costly and smaller than you think when you include code reviews, ops work, and design. As an engineer you need to be ruthless about your priorities and work on the most important ticket at the moment. But it’s also important to recognize that customer facing work should not always be your #1 priority. You need to factor in the long term growth of the product and the resulting codebase. To make this commitment as an engineer you may have to separate yourself from a customer for a decent period of time to give yourself the space to think about long-term facing features and their requisite system design. This can be tough for some engineers who love to deliver business value but it’s important to keep in mind that the overall goal is to build the best product possible and not over optimize for one customer.
Shipping velocity is extremely important for any startup to succeed. But in the I past I confused shipping velocity with hacky fixes and untested code. That’s just delaying your pain. And in this day and age, nothing pisses people off more than bad software.
When considering high-quality shipping velocity we immediately default to that meaning having the best engineers on your team. That’s certainly true but I’m become a firm believer that amazing ops makes an even bigger difference. This includes robust CI-CD pipeline, well-managed developer consoles, a focus on unit testing, and a culture of high standards (more on ops in a later blog post). When I joined Dolthub, I was surprised we already had a person working full-time on ops (this might be a common thing but I hadn’t seen it before). But he’s made us 10x more confident in the code we’re shipping. We are constantly confident that our product quality never drops. Product quality 100% compounds so when your product is consistently getting better you have a much better chance of it becoming incredible.
As an individual some mental models I’ve adopted to hold myself to higher shipping velocity include:
One of the best articles that I’ve read that completely shifted my perspective on engineering is this article by Shyam Sankar (COO at Palantir). What you want to cultivate is a team of artists who are focused on delivering the best product possible with the understanding that individual ownership is a myth with modern software development. What process only serves to do is reduce the creative scope of your engineers. Jira boards, sprint reviews are not high leverage things that cultivate artistic expression. What you really want to focus on when working with engineers is optimizing the balance between shipping features that deliver customer value with features that are really interesting intellectual challenges (I stole this from my boss). It’s important to note that all of this is predated on each individual artist caring about their work but not about about the credit itself. Would you ever buy art from artist who didn’t care about what they produced? Is it okay for the symphony conductor take all of the credit for the orchestra’s performance? No!
Process can theoretically nudge people into more ownership, but even better is hiring people who care about the quality of their output. Don’t compromise on the latter at a startup.
Thanks for reading! More stuff coming soon :)