Why Twitter had 7500 Employees, and Startups Crush Big Companies.
Long-term vs one-time cost of product engineering is a core reason why companies grind to a halt over time.
Why does Twitter have thousands of engineers, when a single good engineer can build a prototype of Twitter in a few days?
Why do startups of 10 people seem to build code faster than teams of 100 at a larger company?
Why do products seem to change rapidly at first, and then you notice years have gone by without significant improvement?
Let's look at Alexa. When launched, it had a basic set of features, and new ones appeared rapidly. It was pretty exciting and ground-breaking.
During the time of which Alexa went from hundreds to many thousands of employees, the corresponding rate of change (for external customers) seemed to decrease. Behind the scenes, there are changes taking place, but the experience for most users hasn't fundamentally changed in years.
What is it about growth and scale that slows down the pace of development?
People productivity math
You form a technology startup. How much productivity are you investing if you invest one person week per week?
One person week doesn't necessarily tell you anything. Because you aren't selling time to your customers, you're selling a product. What's important is your generation of new value in your product. How much value you create through your effort. How would we represent that in a formula?
🔨 New value per week = (Your Productivity) * One Week
Every week you write new code, and build new features. New value is added into your product. If you're an excellent engineer, your productivity is high. If you're a poor engineer, your productivity will be low. Regardless, you're adding value every week.
I've heard from executives that they want to make their teams "produce more". The underlying assumption is that the "Your Productivity" calculation for each employee needs to be increased.
In most cases, this is the single least valuable element to address. If you're motivated to do your work, and you're already working in the ballpark of 8 hours a day, is there a reasonable way to make you "work faster"? You can use slightly more effective tools, but that won't do much. You can have faster hardware, but in most cases that's a small, marginal improvement.
The speed you type is unlikely to change much. The speed you think is unlikely to change. Your knowledge of how to do your job is unlikely to change (other than natural experience over time). The fundamental amount of value you add every hour is not going to drastically change regardless of what management motivation someone employs. And I'm going to thoroughly ignore the idea of working 10-12 hours, 6-7 days a week. Because I think that's short-sighted, and I'm not going to address it in this article.
A smart person engaged in their project has a static ability to perform work. We need to look elsewhere for productivity.
What is the first productivity variable to identify?
How hard it is to add that specific feature / value to your product. Some features are easy to add. Some features are hard to add. This modifier isn't random, either. It's frequently in your control.
🔨 New value per week = (Your Productivity * New-work Difficulty) * One Week
How can value be easier or harder to add?
One obvious answer is your tool choice. X technology is better than Y technology. That's true, but heavily overstated. Look across major technology companies, and you'll see comparable features built in many languages, using many tools. If there was a tool or process which was fundamentally more efficient, you'd see the companies using it crushing their competitors.
Agile vs Kanban vs Scrum companies don't seem to have advantages over each other. And Ruby on Rails vs Python doesn't seem to be the dividing line between successful and unsuccessful companies. Once you learn an appropriate tool, it tends to get the job done.
So let's discuss another way to influence how hard it is to add value.
Imagine you're building Goodreads. Your first version of Goodreads will be a list of someone's books.
Work to build the first version of Goodreads.
Create user accounts, and a database to store them, and login functionality.
An "Add Book" page.
Create a database to store books.
The "My Books" page to show the books you've added.
User accounts. Two pages. A database. Ok, not terrible. You've built Goodreads. Good job. Jeff will come along with a check for $150 million any day now.
Now you want to add cover art to books. Tiny little update. According to most product managers, this shouldn't take more than 5 minutes. Not that I've had conflicts with product managers in the past. Never.
Here's the work involved to add cover art.
Change the "Add Book" page to include (optional) cover art upload.
Change the database to store cover art.
Change the "My Books" page to show the cover art, if available.
Notice that you needed to make a good number of changes to add one small cover art feature.
Why is that? Because of the interconnectivity of the work. Changing books in any way requires changing multiple pages.
Changing or adding features means that for every connection in your system, you have a chance of needing changes.
What if you have 27 features interconnected with 32 pages on your site? Depending on what you're changing, you could easily need to make 25+ changes for a simple change.
What's the single largest variable for how hard an individual bit of work is?
How complex / interconnected it is. If you can manage to make a change which doesn't impact the rest of your product, it could be easy. If the change you're making impacts the rest of your product in any way, it tends to be hard.
As you grow your product, it usually gets more complex. The connections grow inside your system. Imagine a product like Amazon's retail website. The site supports various languages, digital and physical products, multiple ways of displaying products depending on their category, internal and external ads, a hundred currently running beta tests, wish lists, and on and on and on. The smallest changes can easily take 30-60 teams working for weeks to implement. Because everything is connected. A company with a simpler website could make the same change in literally 1% of the time. No exaggeration.
Not because Amazon engineers are inefficient. Because the product is complex. Because for better or for worse, the site supports an enormous number of features.
Now, before I get too carried away on this, I need to mention what happens after your launch. Because you just built Goodreads, and it's time to get some customers.
Maintenance and productivity
You've launched. Now you need to maintain your product.
What kind of maintenance?
A user reports a strange bug. You need to research it and fix it.
A different user points out that the VAT rules in their country changed recently, and they need their current and future payments fixed. That's something you have to research and probably fix.
Your product uses the XYZ open-source package, and it has a recommended security update. You have to update to the latest security patch.
A user pointed out that extremely large cover images makes the site slow down. You need to change how images are scaled when they're uploaded.
What's the core difference between the work of building a product, and the work of maintaining a product? Building new features adds value to your product. Even if the work gets harder over time, at least you're adding more value.
Maintaining a product is about maintaining the current value. Maintenance work is a regular payment in the fight against entropy. Over time, your product will die if you don't continually feed and water it. Technology changes. Regulations change. Customers change. Hardware changes. Common packages change. It is rare that software can run for any length of time without relatively major effort put into it.
Let's update that calculation for the value you add every week.
🔨 New value per week = (Your Productivity - Maintenance work) * New-Work Difficulty * One Week
The thing about maintenance work is that it literally subtracts from the time you have available to build features. The time remaining is the work you can put towards new features.
Now you're sitting there, maintaining your product. You're frustrated that you're not making much progress. How do you start making progress again?