,
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...
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.
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*
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".
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).
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.
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 🤔
