Profile picture
, 13 tweets, 2 min read Read on Twitter
Thinking about scaling your team is not dissimilar from scaling a web application. Stay with me 👇🏽

An app starts out with a single read-and-write database, and zero caching. The code is simple, and there's a single source of truth...
A read query will look something like this:

How many users do we have? → Check database → Counts the row in the users table → Returns 100.
Over time, the database will become overwhelmed with requests and a caching layer is added. In general, a caching layer is about 100 times faster/cheaper than accessing a database directly.
This changes the flow above to something like:

How many users do we have? → Check cache → Not in the cache → Check database → Counts the row in the users table → Returns 100 *and puts 100 in the cache*
Once something is added to the cache, it looks like this:

How many users do we have? → Check cache → 100 is stored in the cache, no need to ask the database → Returns "100".
(Things can be removed from the cache when the database changes, and a "miss" is required to refill the cache with the new value from the database.)
Over time, strain is removed on the database because more and more things are put in the cache, allowing the database to do all the other things a database can do…
Now, think of your team members like a database. Your internal docs and process will act like a cache – a faster, cheaper, protective layer that gets "hit" before it.

And instead of users, it's other team members are the ones making requests to the database (each other).
In both cases, a source of truth is constantly being asked to do some work that results in the same answer over and over again. To save time and money you should build a culture of answering it the first time, maybe the second, and then put it in a cache.
This cache can be an internal document, some piece of automation, or something else – anything that acts as a middleman between the entity making the requests and the source of truth. Ultimately, the goal is that the "database" does not need to be hit twice+ for the same answer.
Just like scaling an app, you can measure and optimize for cache "hits" and track cache "misses," creating a culture in which people can rely on a reliable cache instead of always having to hit the database directly.
For example, if every new employee requires someone to manually add them to Slack, you can scale that…

Pre-caching: "Hey, can someone add me to Slack?"
Post-caching: Joins company → Reads an on-boarding document → Sees instructions on how to add themselves to Slack and does.
Then, the hardest thing about scaling the company in this way is keeping internal processes and documents current and making them surface appropriately. It turns out, computer science has similar issues 🤔

Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Sahil Lavingia
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!