Developing Mechanisms for your Org: The 50->500 Framework
50->500 framework for building mechanisms for your Org.
When Alex, a senior engineering lead, joined NextAI, he eagerly implemented the strategies that were successful at his previous FAING company. He rolled out similar workflows, planning meetings, and introduced his favorite tools, confident they'd lead to success. But instead of thriving, his new team stumbled—projects slipped and morale dipped. Alex was puzzled that his old playbook didn't fit this new game.
That reads like a fictional excerpt from Three Dysfunctions of an AI Executive but the story is not unusual.
I worked at multiple startups before I worked at AWS. It was a big change to go from a startup to AWS - there were more people on my first Large Scale Event operational review (250+) for DynamoDB’s outage than number of employees at a small startup! Similarly as I moved to Cash App, the culture was quite different from AWS.
Across these startups, two large services in AWS, and Cash App more recently, I found the 50→500 framework useful to keep in mind as you develop mechanisms at a new org.
The 50→500 Framework
Mechanisms (e.g. Operational Reviews) should be evaluated in context. Outside of people reasons, a big reason new mechanisms fail is that the context they previously operated in, for e.g. at Microsoft, is significantly different than at the new company. Another reason they fail is that they are not effective at this size. Let’s dig in to each.
1. What boat are you operating?
If you are operating a small speed boat, you likely don’t need the same navigation techniques used by the captain of a large cargo ship. The cargo ship captain will rely on advanced GPS systems, sophisticated radar equipment, and navigators to plot the course and avoid hazards. However, these tools and strategies may not be needed or even useful for a small speed boat captain, who may be able to rely on simpler navigation tools, and their own intuition and experience to navigate.
In a large company, there are more resources, more stakeholders, and there is more complexity to manage. They are also hard to pivot quickly. Smaller companies have fewer resources, fewer stakeholders, and significantly more flexibility to pivot and iterate. Processes that are designed to optimize and standardize operations in a large organization may not be suitable for smaller teams that needs to remain lean, agile, and adaptable.
As an organization leader, understanding the boat you are operating and it’s context/strengths is important to the mechanisms you apply to operate it. For e.g. unlike my previous startups, big services at AWS were like large ships, it took time to turn them but once you get them pointed in the right direction, they can travel with speed and have massive impact. When I joined Cash App, we were earlier in lifecycle, able to pivot quickly with a strong culture of bottom up innovation. Any mechanisms we employed had to embrace that.
Do these mechanisms have multiplier effect on your team’s strengths and align with objectives at this stage? Mechanisms that you apply to your team should leverage and play to your organization’s strengths. E.g. Startups or small teams win because they can be nimble / quick to react. As a result, the mechanisms that you implement when your team is small should leverage the shared context and ability to react extremely quickly. These practices should build greater flexibility, facilitate quick customer feedback and drive agility in development, experimentation and decision making.
2. Does the mechanism work at this size?
As your team size changes, mechanisms that work at one order of scale may not work at next (or two) order of size. The initial temptation for most teams and leads is to pedal harder on the mechanisms that have worked so well and optimize them. Initially that helps but it stops working with continued growth and then additional effort does not make much difference. You need a different set of mechanisms.
The reason it stops working is that the complexity grows non-linearly with size, and you just need a completely different mechanism to deal with different stages of that curve.
Let’s take one example mechanism (1:1s) and walk through this. When your team is very small, you can do 1:1s with everyone to share context, catch issues and gauge team health. As your team grows to say 35 people, you start to stretch this mechanism by ‘pedaling harder’. It’s harder to do 1:1s with everyone but still possible to meet everyone and build context.
As you grow past 50 …. 100..300 people in your team, pedaling harder on the same mechanism (1:1s) does not work - you need to rely more on mechanisms (and organizational structure) that provide signal at larger scale than direct connections. The key reason this mechanism needs to change significantly is that as your team grows - the number of people you directly meet will be a small fraction of the total number in your team. You need to start developing other mechanisms to get a signal similar to when your team was smaller.
As you go from 50 —> 200, you go from direct 1:1s to leveraging your organization structure to share context, and build in multiple other ways - 1:1s, skip 1:1s, group chats, office hours, broadcast channels, all hands and you start to rely more on metrics (e.g. attrition rates..) and data (e.g. surveys) to determine team / people health.
You still need to dive deep (more on that in another post) so you are grounded but you just cannot dive deep on everything. You need your mechanisms to give you good signal for when to.
Similarly for other mechanisms, think about the 50→500 framework and see how to evolve the mechanism as the complexity grows. We will cover this in the next post.