👋 Hi, this is Gergely with a subscriber-only issue of the Pragmatic Engineer Newsletter. In every issue, I cover challenges at Big Tech and startups through the lens of engineering managers and senior engineers. If you’ve been forwarded this email, you can subscribe here. Thriving as a Founding Engineer: Lessons from the TrenchesBeing a founding engineer at an early-stage startup is a vastly different, broader role than many people think. Lessons from “serial” early-stage and founding engineer Apurva Chitnis.
It’s common for early-stage startups to hire “founding engineers,” who are so called because they’re among the very first recruits. A couple of distinguishing features of the role are generous equity packages (between 0.1 and 1% of company stock), and the fact that expectations are frequently broader than typical developer roles. Apurva Chitnis is the ideal person to tell us what makes being a founding engineer unique, and to answer questions in the kind of detail that only comes from being on the ground, doing it. And Apurva certainly has done it, almost on repeat:
In this issue, Apurva covers:
Finally, in the takeaways we’ll go over how Uber was almost shut down a few months after hiring its first mobile engineer, Jordan Bonnet. He and I worked together for 2 years, including during the ride-hailing app’s epic “YOLO” rewrite. Jordan happens to be available for hire, so if you're looking to build a world-class mobile experience, then reach out to him! The bottom of this article could be cut off in some email clients. Read the full issue uninterrupted, online. Relatedly, also check out From the trenches: working at a startup vs in a Big Tech. To keep up with Apurva’s writing, subscribe to his newsletter. With that, it’s over to Apurva. 1. The goal of a founding engineerBefore discussing how to work at a startup as a founding engineer, let’s first define what a startup is. So, a short story. During my career, I’ve attended hundreds of all-hands meetings, when the whole team comes together for important company events, like introducing new recruits, strategy changes, and to share updates and successes. Among them all, one at Improbable has stuck with me. The chief of staff sketched out our financials in the all-hands; plotting costs, revenue, and predicted revenue growth. He combined them to calculate how our bank balance would change over the next year. This led to a painful realization: our startup was going to run out of money and go bankrupt – unless things drastically changed.
This was a bold call to action for us all, to focus all our energy on projects that increased product usage and therefore revenue. Everything else had to be ignored! The race to product-market-fitAll startups begin as “default dead,” meaning their starting trajectory inevitably leads to bankruptcy. According to a 2022 research by Startup Genome, 90% of startups fail and shut down. This is a truth you need to acknowledge and lean into: that if things don’t change, the business will fail. However, there is a proven path to avoid this outcome:
A software engineer’s responsibilities evolve with the company; from founding, to an exit via an IPO or acquisition, hopefully. A founding engineer’s goal: find product-market fit!As an engineer, your goal is to help your team achieve its goals. As a founding engineer, your team is the company, so the first priority is to build something people want. This is the product-market fit. Without PMF, companies struggle to grow, retain users, raise funding, and become profitable. If no PMF is identified, startups end badly. Your goal is to find this all-important PMF, and don’t let anyone tell you otherwise. This constraint affects all aspects of a founding engineer’s work:
If you’re working in a leadership role, the need to find PMF also affects how you build and organize your team:
It’s necessary to think beyond writing code, building features, and solving user needs. A founding engineer’s aim is to build out a company-wide system which enables the business to find its PMF. Remember, you’re a founding employee. Success means achieving PMF for the company, and then taking it to the next level. Make this your focus when taking decisions! 2. Approaches for successAs a founding engineer, there are countless decisions to make which impact the product and tech stack, such as:
So, how do you make these choices, and how do decisions change as a product evolves? A founding engineer must make them pragmatically, using knowledge of the business, product, and users, for guidance. Business uncertainty is a big driver in engineering decisionsBegin by taking these factors into account during design decisions:
You’ll notice most of these constraints are external to engineering; they’re about the business itself! Prioritize flexibility during uncertainty. The younger a startup is, the more “cloudy” are the user, product, value proposition, channels, and business model. Early decisions are based on high-level vision and intuition about what should work. As you test ideas in the real world, you’ll need to iterate fast. So, as an engineer, prioritize flexibility in your decisions so the product can change rapidly and evolve. As you iterate and the product (hopefully) moves towards PMF – not usually a straightforward process! – you develop more understanding of its requirements, meaning you can justify investing time in building an architecture that targets users’ needs and the product’s aims. Evolve your technical decision making as the product evolvesYour decisions must evolve with the product. The right decision on day 1 is almost certainly not the right one on day 365. This was our experience of building our app, Shelf, over the past year. As a reminder, Shelf is an app that connects users with the media they and friends love. Start simple. We started with a basic data model. New songs a user listened to, TV shows and movies they watched, and books they read, were stored as new rows in an append-only table called
This spartan data model allowed us to build a highly-functional minimum viable product (MVP.) It was even flexible enough for us to implement new features, including ones we didn’t think of building our MVP, such as weekly recap, which allows users to see a summary of the media they had consumed in the past week; and history, which allows users to see other songs, books, tv shows and movies that had previously been on their Shelf. Notice the cracks. However, as our product became more functional and complex, cracks started to show:
Migrate when it’s really necessary. Too many of these issues piled up for us, so we decided to migrate to a data model better suited to the product’s and the engineering team’s needs. By this point, we had a better understanding of our app, its constraints and opinions, and the abstractions we wanted to work with as engineers. Given this context, we were able to design a more effective data model. There were two key insights. The first was to store
Understanding how a user’s top artist changed became as simple as digging into two rows of data in this table. Previously, we’d had to aggregate thousands of rows in the The second key insight was to store progress, such as play counts, pages read, and current episodes, as a first-class object in our data model:
Understanding a user’s progress through a TV show, movie, book, etc, was much easier, as we simply needed to look up the relevant row! Building this new data model required much greater investment in time to design and implement it, compared to data model v1. Our work paid off, though. The new data model allowed us to build new features faster and at higher quality. When we started building Shelf, many things were uncertain. We didn’t really know which features would resonate with users, and our vision of the app was blurry. But after a year, we had gained more certainty about the product’s direction and we were able to make more “expensive” decisions with greater confidence, such as investing in a better data model. Your job is more than building featuresBuilding features is one way to help a business achieve its goals, but it’s not the only thing in your toolbox. Founding engineers use tools which have nothing to do with code, at all! At Sidetrack – a company I cofounded to reduce cloud hosting costs – my most productive period was when I wrote very little code. This was early in the company's lifecycle, when we believed we could reduce cloud costs by shutting down virtual machines that had low utilization, thereby saving their expense. But how could we test this hypothesis? Building an MVP of a working product would have taken months. We were in the business-to-business (B2B) market, and our target customers were large enterprises with several dedicated infrastructure teams. These orgs would obviously not let us run a service that wasn’t properly tested and vetted. There was also the problem of sales; even if we did pull off a rock-solid MVP, we didn’t have anyone to sell it to! So, step one was to find companies potentially interested in working with us, as we built the real version of the product. Here’s how we went about locating them:
Step 2 was key for progressing to PMF. We had no problem finding customers, but we needed to get their attention. Otherwise, there was no point building anything. Instead of starting to build the “real” product, I wrote a scrappy Python script. This script demonstrated to users how much money they were wasting. The script only took a few hours to write and was very simple. It had two inputs: the workloads our users wanted to run, and their CPU and memory demands, and also the infrastructure they were able to run on, and their CPU and memory supply. The script calculated the minimal infrastructure needed to run these workloads, solving the bin packing problem using an off-the-shelf optimisation library.
We then ran this script to calculate how much potential customers were wasting on unused compute. The results were surprising: we found teams were paying up to 4-5x too much, even when accounting for surge capacity! Simply having this information got people excited enough about a real version of our product to sign prospective contracts to continue working together. These companies were then happy to spend time talking with a young startup because they saw value in our approach. This scrappy script also validated the existence of demand for our solution, not just for securing early customers. This commitment was gold dust when it came to raising investment from VCs, who wanted to see early signs of traction and market validation. As a founding engineer, the job is to do what it takes to help the company reach its next milestone. This lesson was clear, even as later, we pivoted from cost optimization to something better suited to our backgrounds in product management and engineering. In this example, this meant being creative to get people’s attention. It also involves other things, such as:
Think broadly about your role and contribution as a founding engineer. Don’t limit yourself – mentally or otherwise – to working on product features! Scope, quality, timeline: pick twoOften, you want to a build a product feature that is:
My concrete experience is that you cannot do all three with limited resources, so the pragmatic approach is to choose two. But which ones? It depends on your company and the market. For startups, “quickly” and “high quality” are often the preferred solution because they force you to reduce scope. You should choose high quality over broad scope at a startup because an unreleased feature is a gamble. You don’t know for sure it will have the impact you expect until it’s released and users’ reactions are in. Implementing functionality takes time, obviously. Reducing scope allows you to learn from users and to iterate fast, giving you time to quickly test another hypothesis and approach if the first doesn’t work. Reducing scope is also a great forcing function to focus on the core of your idea, pushing you to cut everything that isn’t core. Being able to ruthlessly cut unneeded functionality is a hallmark of an effective founding team. When deciding the scope, a founding engineer can – and should! – provide context on what gives the best “bang for your buck.” It’s rare for a founding engineer to own the decision of what’s in or out of scope: the founder or product manager owns this decision. However, founding engineers can – and should! – provide context to the product person about which features are the most time-consuming to build, and why. The best founding engineers help their team understand feasibility and complexity, even before the feature is designed, and especially before engineers start building. This kind of conversation is a regular one at my current startup. Just last week, we decided to de-scope a new feature called “stories.” We cut the scope to limit the feature to current users. The “stories” feature won’t be shown to new users we onboard to the initial version. A tech stack is merely a means to an endAt Improbable, my first project was to check the correctness of the distributed game engine we were building. I did this by performing an integration test. I outlined my thinking in a design document, listing the taks:
Satisfied with my thorough approach, I shared my proposal with teammates in the expectation of receiving congratulations. Instead, I got immediate pushback! Someone said building would take too long, someone else said it would be near-impossible to maintain the custom reinforcement model-based AI, and another didn’t even think I could make it work, and that it was probably unneeded, anyway. It turns out I didn’t actually need all this complexity; I didn’t need a complicated, reinforcement model-based AI, even though it would be fun to implement. The goal of the project was to answer the question: “Is our distributed game engine working or not?” A very simple simulation would do, wherein tanks interacted with each other using a very simple, rule-based logic (if-then-else). I built this in a fraction of the time that reinforcement model-based AI takes, and finished the project in a couple of weeks, not several months. It’s tempting to reuse old technologies and patterns – but avoid this temptation. Reusing what I already knew was exactly what I was doing: I had just finished my engineering degree, and spent the year prior building theoretical machine learning models – including reinforcement learning. It was instinctive to use that tool for a design challenge, and I’ve seen this so many times at early-stage startups:
I don’t recommend copying old approaches, as they often come from very different environments:
Don’t forget, all startups and companies are different. If you know which technologies are appropriate for your context, then great – use them! If not, carefully reflect on why technologies you used in previous experiences worked, and whether they’re actually appropriate now. A final note on the tech stack; as an engineer, you likely take pride in things like writing elegant code using TypeScript, and managing your infrastructure using Kubernetes. However, users and the business don’t care about this! All they care about is impact: the usefulness of the product, and whether it solves their problems. 3. Tech debt...Subscribe to The Pragmatic Engineer to read the rest.Become a paying subscriber of The Pragmatic Engineer to get access to this post and other subscriber-only content. A subscription gets you:
|
Thriving as a Founding Engineer: Lessons from the Trenches
Subscribe to:
Post Comments (Atom)
Your Brain on Art
My Q&A with Susan Magsamen and Ivy Ross ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ...
No comments:
Post a Comment