How to prepare to be a startup founder

Tree growing around bicycle

This is a guest post from Joyce Park. Enjoy.

To my newer colleagues:

Welcome! I’m so excited to have you in the dev community, and honored to hopefully be able to contribute by sharing a few time-tested hints about entrepreneurship and early-stage startups.

I’m a community-taught web developer who has enjoyed 22 years in high-profile startups – mostly writing PHP and React – but also I’ve been a two-time startup co-founder myself, raised $10mm in venture capital, been written up in a bestselling business book (Give and Take), and am co-founder of the world’s largest meetup for entrepreneurial engineers (@106miles). Since the first week of 2005 – so for 17 whole years now! – we have been helping Bay Area techies get the information they need to found startups without getting horribly taken advantage of. And let’s get real here: the whole startup ecosystem is basically designed to take advantage of your technical talents and also your lack of business acumen. Remember that during the Salesforce IPO it turned out Marc Benioff the business founder owned almost a third of the company while Parker Harris the tech founder owned 2.7% – barely more than their first angel investor.

If you even suspect you might want to someday become a startup founder or founding engineer, I’d like to suggest a couple of practical tips that prepare you for that path.

Learn the basics of venture capital

You don’t need to fear venture capital – remember, they work for you! – but you need to understand the mechanics of how the system works. The easy move here is to read this recent book by the operations partner at top VC firm Andreesen Horowitz: Secrets of Sand Hill Road.

“Operations partner” means Kupor’s the guy who makes the checks show up in your bank account on time once someone else decides to invest. So he doesn’t have that much to say about how startups are SELECTED but he can explain much about what happens AFTER the selection process.

You may or may not have already had the opportunity to learn about the venture capital system from the employee point of view, but in either case this is a good quick overview by former Uber dev Gergely Orosz.

However, remember that the entire available stock pool for employees is generally only between 10 – 15% of mostly non-voting shares! It’s super important to your employees but still only one of the interests you will be mandated to balance when you’re a founder – and a minority interest at that.

Make friends outside your business area

The single biggest mistake I see from early engineering founders – and one I have made myself more than once! – is that they don’t understand how to reason backwards from business models to products. In particular, first-time engineering founders tend to believe other people will sign on to their project because the PRODUCT is so cool and not because the BUSINESS is well thought out.

This article provides a very clear example of understanding the difference between hacking features versus hacking business models. Evite was an older, stagnant, undervalued business that got a new CEO who found whole new revenue streams with only minor tweaks to the product. Even extremely technically sophisticated products – Roblox is a great example here – really took off when they started focusing harder on business model rather than cool demo. I’ve gotten to the point where I don’t even want to know about most 106 Miles members’ products… I just want to know what business they think they’re in.

Business models do evolve over time – for instance self-serve subscriptions were really hard in the earlier years of the Web but now are a foundation of modern computing – so I can’t exactly tell you the precise one you will need to master to succeed in the future. However I can guarantee that you will need to understand the major channels by which revenue can flow to your company, which means you need to understand either bizdev (consumer) or sales (enterprise/cloud) or some combo – and in any case you will need to understand marketing.

I can’t emphasize this point enough: if you aren’t willing to learn about revenue and marketing, and think HARD about it, you aren’t ready to be a founder. And I mean you need to drop the engineering-superiority shitkick and learn from a place of humility because the business model is by far the reason most startups fail. If you’re in B2B, you need to go on some “sales calls” (real or mock) where you talk to potential customers. If you’re in B2C you need to understand how the advertising and lead-gen businesses really work. In either case you’ll need to find out how much it costs to run a successful go-to-market campaign.

Since you’re early in your entrepreneurship journey, the easiest way to learn what you need to know is to look for friends in these functional areas who you can bounce ideas off of. If you eventually decide you need a co-founder, that person will likely be from this pool… so there’s some motivation to hit the marketing meetups and schedule some coffees with salespeople you might know.

Speaking of cofounders… I have way too much to say about this topic, but let me just leave you with one tip: before you start a business with someone, go on a long (minimum 10 day) trip under difficult circumstances (hiking, biking, crappy car) with them. NASA does this to quickly shake down space shuttle crews. Their rationale for the long trip is that anyone can front for a weekend but it’s hard to maintain your social mask after about 5 days without the perks of home and money. You’ll quickly find out how the other person tries to solve problems, how they deal with setbacks, and what fundamentally motivates them.

Practice storytelling

Being a founder means that you’re going to be telling your story over and over and over again: to raise money, to launch your product, to market your product, to recruit, and to exit. The more successful you are, the more of your value to the company will be in this area. And yet most tech founders don’t give much thought to communicating their company’s story, and they don’t take opportunities to practice before the skill becomes a life and death issue for the company.

Even though I’ve given many tech talks – and I recommend it as a great way to exercise your presentation muscles! – I learned the most about it from a cheesy-looking book about Steve Jobs: The Presentation Secrets of Steve Jobs.

The number one lesson I took away from this book was to ask myself harder, “Why should anyone care about your thing?” Honestly that’s what every meeting with a funder is going to be about, and if you can’t answer this question crisply, succinctly, and in a way that excites them… you should re-think your project until you can. Don’t just take it from me, take it from Midas List venture capitalist Garry Tan:

Become a founding engineer

When I was a baby entrepreneur, a venture capitalist once said to me, “Everyone in Silicon Valley came here to work in startups” – but this is less and less true now as bigcos have become more and more dominant in the whole tech industry. I honestly find it impossible to imagine going straight from rocking a company hoodie as you ride the company shuttle bus to your job at a FAANG, to a new reality as a grungy startup founder where you’re going to be cleaning up forgotten leftovers in the kitchen and hiring 12 lawyers at a time. The situation is even more stark for entrepreneurial engineers from areas with few tech startups, who maybe didn’t get a lot of opportunities to learn from close contact with founders.

My entire career has been in pre-IPO startups, and I don’t think you can learn what they’re like without working at a couple of them. But also, I feel that being a company founder is a lot like being a novelist: it’s not a career move, it’s more like having malaria – a fever that recurs periodically. By being one of the first five engineers at a newco, you can try out the lifestyle and see a lot of the shenanigans up close and potentially make a lot of money… on someone else’s dime. Yes there are risks, but an unspoken secret of big companies is that they’ll almost always take you back without much hassle.

A lot of 106 Miles members actually end up deciding they don’t actually want to become founders – that the potential rewards aren’t worth the extra stress, or that their idea maybe isn’t quite strong enough for a standalone company but could be valuable to a complementary startup. There’s nothing wrong with any of this! Great founding engineers are worth their weight in gold to a startup, and they are not easy to find.

This might be a good time to say a few words about the role of the founding engineer, because it’s one of the worst-understood roles in the entire tech business. My friend Dan Moore, under whose auspices I am writing this letter to you, has written a well thought out essay about how founding engineers need to be well-informed, wise, and probably pretty senior. Meanwhile I’ve worked at MANY hot startups and Open Source projects where the founding engineers – the guys (and they were 100% guys) who banged out the initial bits for the MVP – were young, smelly, and profane but able to bust out working code on the quick and dirty.

It is so critical for founders to understand that when you do a newco you’re placing two bets – a business bet, and a technical bet – that trade off against each other. The business bet is that you’ll find product-market fit before your tech debt screws you, and then you’ll have the money to hire an experienced team to rewrite your code when it matters. The technical bet is that quality software will make your business work, and then you won’t have any tech debt to deal with going forward because your software will be perfect – but this never happens. Optimize on winning the business bet ASAP by using quick-and-dirty founding engineers, and you’ll see that money-cash-devs can wipe out all your technical debt pretty fast if properly deployed.

What kind of founder do you want to be?

See this tree growing around a bicycle? The tree is your company, and the founders are the bicycle. Less poetically, founders are the cat piss that you can never get out of the carpet. For better or worse, as a founder your strengths and weaknesses, your quirks and blind spots, your early network… all of this will be reproduced in the company in a way that makes it difficult to reverse. The major method by which this happens is hiring, especially hiring people who become leaders in the company early on.

That means if you care about certain organizational practices, you need to address them WAY EARLY. For example, diversity and inclusion: once you hire the first 10 devs, you are very likely to have the same demographic mix that they represent when you have 100 or 1000 devs. Sorry, we all want this to not be true! But if you care about hiring people who reflect your customer base, you need to think about it from DAY ONE. If your product will mostly appeal to women, you better be thinking about how to hire women right away. If your target market is Latinos, better hire some. If you want to bid on military contracts, maybe hire from the ex-mil pool. If you have a plan and stay ready, you won’t have to get ready when things are hectic.

This may not be your specific issue, but all founders need to think about their deepest ethical values before they start – from the point of view of what would be best for the company, not you specifically. As a personal example: because I’ve had multiple life-threatening health conditions and my heirs are all far older and non-technical, I had it written into my contract that if I die my co-founder will vote my shares but all financial proceeds will go to my estate. This allows for the company to continue to function in a way that it couldn’t if my non-technical heirs suddenly were forced to make important decisions for a tech company. When you become a founder the good of ALL THE STAKEHOLDERS in your company becomes your primary responsibility; and although only you can say how you plan to best serve everyone fairly, I’d suggest that you don’t want to end up the subject of lawsuit or a documentary film accusing you of negligence or egomania.

Join a community of founders

This is a bit self-serving, but I’m gonna put it out there: if you want to become a founder, join up with other founders and learn from them. This is the true secret of Silicon Valley: not that their techies are smarter, harder working, or more connected to venture capital – but that they self-selected to want to learn from each other, and the ecosystem has evolved to support that in a million tiny ways. Organizations like my meetup for entrepreneurial engineers, 106 Miles, will help you get connected to practices and people you can ask for help and talk to – even if you end up rejecting their advice. Come visit us when you’re in Silicon Valley! We may be doing more online events soon as well.

Being a startup founder isn’t for everyone, but if it’s something you have an interest in you shouldn’t wait to learn about it and perfect your founder skillset. Start today! Let me know if I can help – although you should know my specialty is being a “disagreeable giver” – and best of luck!

— Your startup buddy, Joyce

Joyce Park has spent 22 years in startups and Open Source projects as an engineer, an eng manager, and a founder. She recently moved back from Silicon Valley to the Seattle area where she grew up.

Learn caching

Dear new developer,

Caching is a common architectural pattern that helps with performance and scalability. Spending some time learning about this will help you build better systems and understand existing architectures.

What is a Cache?

At the most fundamental level, a cache is a secondary store of a set of values which pulls values from a primary source. There are many reasons why you might want such a store, but a common one is that retrieving the data from the primary datastore is expensive. It could be costly because it is an expensive calculation, because it requires a network call or disk read, or for some other reason.

To avoid the cost of the retrieval, store the value in a cache, and then, when it is needed, retrieve it from there.

Cache Types

There are two main ways to categorize caches.

  • How the data is stored
  • What is stored

Cache data can be stored the same way any data can be stored. In practice, for most applications, you’ll be looking at a few options:

  • Memory
  • Disk
  • Abstracted

Caches that are stored in memory are quick (yay!) but ephemeral (boo!). The cache can go away at any time (whenever the server maintaining the memory is shut down), which means that you can lose access to the cached items at inopportune times. In addition, a memory based cache competes for RAM with other elements of your system. In general, most systems have less memory than disk, which is an alternative storage mechanism.

Retrieving items from disk is slower than memory. Of course, this is true for all disk access, not just that of cached data. The upside of a disk based cache is that you can store far more information.

You can often switch between memory and disk easily and transparently to your application’s code; consult the cache’s documentation to learn more about this option.

The last type of cache is ‘abstracted’. This means you use a cache as a service and don’t really care about the underlying implementation. This could be part of a framework (rails caching, for example), a standalone program like memcached or redis, or a full fledged service like a CDN. Browsers are a cache too. You don’t have to care about the details of this abstraction to take advantage of it. However, you will need to have some understanding of the cache behavior and performance when you operate your software.

Cache Keys

Most caches have a key and a value. The value is the cached value. The key is something that can be constructed by a client to get to the value. There is an implicit communication between the process that puts the value in a cache and the processes that retrieve a value from the cache: they have to agree to how the key gets constructed. Otherwise the cache readers won’t be able to actually read the correct values from the cache.

If you have product data that you are caching, you might have a key of product-<productid>. For a product with the id 15, the data would have a key of product-15. The product prefix namespaces the id in the cache so you can have multiple different types of objects cached (categories, deals, etc). The product id (15) needs to be known by the client to get the data.

Evictions

At some point, your cache will run out of room to store new items. At that point, it will need to get rid of some old items. This process is called ‘eviction’, and there are multiple ways to configure a cache to evict old items:

  • Least recently used (LRU): evict the items that were accessed furthest in the past.
  • Least expensive. If you are caching calculations because they are difficult/expensive to perform, evict the least expensive calculations first.
  • Oldest: evict items that are the oldest. This is also known as first in, first out (FIFO).

Sometimes it can be hard to judge which of these will be the right fit for your system, especially since you may not have a good grasp of usage patterns initially. Generally LRU is a safe choice to begin with.

You should also think about how to trigger evictions. This might occur if the item being cached is materially changed. An example is a new logo for a website. You might want that to be cached in a CDN for years, because it rarely changes and is used everywhere (so you might set the cache period to a long time). But when a new logo is included in a launch, you want to ensure it is used. One way to manually trigger a cache eviction is to use a new name for the logo file.

You might also want to evict a cache item when the underlying source of truth has changed. For instance, if you are displaying the price of an item, when the price changes in the underlying data, you are going to want to display the new cost right away. So when the price changes, you’ll want to force-evict any cache you have. You don’t want someone thinking they can get the product at $X, only to find they are charged $X+1. Not a fun conversation with the customer.

When Should You Use a Cache?

Caches optimize access but introduce complexity. A system is always easier to understand if you pull from a single source of truth.

Introduce a cache when the performance and scalability benefits are required. Otherwise you are simply prematurely optimizing. How do you know if they are required? Evaluate the performance of your code. You can do this by inspection and reasoning about the code. It can be easier to run tests with the cache both disabled and enabled if it is easy to integrate. If you don’t see big changes in performance, there is probably a different slow area of your system.

In addition, think about how expensive a retrieval from the primary datasource is. This will change over time based on your usage and the type of request. You’ll need some metrics to make a good decision as well as to determine if the cache actually helps. Yes, you can introduce a cache and have things be slower, especially if you are on a resource constrained system or you misconfigure it.

Also, consider how much effort it will be to introduce caching. If it is easily supported in your framework or you can add some headers to your HTTP response, caching can be simple to introduce. If it requires you to stand up a whole new system and refactor clients to use it, it can be difficult.

Finally, there are some caches that are built into systems already. Take some time to learn about them; there may be easy wins by tweaking the configuration. Linux has caching as do most databases.

Conclusion

As you might have gleaned from all the examples I mentioned, caches are everywhere. Learning about them and how they can be used is worth your time.

Sincerely,

Dan