How to Transform and Build a People Platform

To the casual spectator, Facebook is having a terrible year. Besieged by privacy scandals, the company was torn into by Congress, the press, and the public alike. To make things worse, the founders of WhatsApp and Instagram left Facebook in what seems to be a complete rejection of the company.

The divide was so deep that WhatsApp co-founder and CEO Jan Koum forfeited up to $1.2 billion so he could leave the company last September—three years after selling his startup to Facebook for $19 billion. WhatsApp’s other cofounder, Brian Acton, left earlier this year, leaving $850 million in unvested options expire. Shortly after, he tweeted that he was deleting his Facebook account.

When a company is racing toward product-market fit and trying to scale their product to thousands or even millions of users, it reaches a turning point. If it wants to compound growth, it needs to transition from a single product team to a people platform that can support multiple teams.

Design principles are building blocks for your company that force clarity and reduce ambiguity by guiding behavior along a set of guidelines. With the right set of design principles, you can direct behavior along a path while allowing the creation of new patterns if legacy patterns aren’t working.

If you try to organize your company on the same model as a Google or an Amazon, you won’t actually build something that lasts. The pediatrician John Gall’s research into the development of children led him to a simple truth about systems:

Amazon’s decentralized, “two pizza” teams work because product teams have a core set of internal tools and APIs that the teams can plug into. Spotify’s “chapters” and “squads” org structure is built around developing a mobile music player and a web app. Trying to copy them blindly ignores the context of your own company.

To build a platform for your team, you have to start by understanding the dependencies between your team and why they exist. Rather than trying to impose a complex system, start with a set of design principles for building a platform so you can adapt and scale.

Doing so means loosening the reins and delegating key decision-making to team members on the ground rather than to founders. That requires taking a huge risk, because you’re ceding control over part of your company. But by designing core principles that drive behavior, you open up your platform to new and surprising innovation from the bottom up.

Here are four design principles that will allow you to build a platform for your team:

In the rest of this article, we’ll walk through each principle and show how to build a platform for your team.

Leaders aren’t born, they’re made. You may be able to grow your team incrementally by hiring a new engineering lead who’s better than a current engineer. But even a mediocre engineer who sticks around, compounds, and expands their role will overtake a Silicon Valley mercenary who jumps around from job to job.

Startups should spend less time looking for leadership to “fix” the company through external hires, and more time trying to create conditions that allow leadership to grow from within. That means flattening the ladder and providing upward mobility for your troops on the ground.

At times, you may need to hire an experienced COO or CFO to help scale. But filling every top rank with outsiders tells your team that there isn’t room for personal growth at your company.

“Hiring the best people” isn’t a sustainable long-term strategy. To build a platform for your team, you have to build leadership from the bottom up over the course of years — not quarters. Finding external talent is a short-term fix to fill immediate needs.

Talent is under your nose if you care to look for and invest in it. That’s the only way you can create a people platform.

By early 2002, as Google’s product line was expanding from Search, the company’s homegrown technology stack grew increasingly hard to navigate. While small teams at Google were developing new ideas all the time, deploying them into production was a different story.

Google needed product managers — people who understood Google’s web of infrastructure and software products and were able to steer new ideas across engineering, design, and marketing to production. The only problem was that these people didn’t exist. So instead of trying to hire external talent, Google flattened their organizational ladder and created internal talent.

Marissa Mayer, an early product manager at Google, bet a coworker that she could train new product managers faster than he could hire them. This training program was known as the “Associate Product Manager” (APM). APMs were sourced from recently graduated computer science majors for a two-year rotational position. Upon joining the company, they were assigned to a product, like Search or AdWords, for a year. The next year, they would rotate to a different department.

The APM program rapidly trained product managers by giving them real responsibility — the first APM was put in charge of Gmail — and cycling them through different products. Instead of just learning how to manage a single type of product, they were exposed to multiple sides of the business.

Graduates of Google’s APM program have not only filled dozens of senior leadership roles at the company but also constitute one of the most talented groups of product managers in the Valley.

Some former APMs include:

The problem with stack ranking is that it localizes performance within individual teams and products and makes it political. When the primary behavior at your organization is political, it stifles upward mobility because people who are in power seek to preserve their power.

As employees carved out fiefdoms within Microsoft from Microsoft Office to Xbox, they competed internally over incremental gains for existing products. In doing so, they were blindsided by external innovations like cloud computing and the iPhone.

As a company scales from a single product to a platform, it needs to transition from a single team to multiple teams piece by piece.

Teams should be loosely coupled. That means there are few dependencies between teams, and teams are able to move quickly and independently. If a product team building a new feature has to ask a sysadmin each time they want to deploy new code, a costly bottleneck is created, which slows down the iteration cycle.

Teams also need bounded contexts — the ability to communicate in a ubiquitous language without needing deep, domain-specific expertise. For example, if product and dev ops are both organizationally aligned with the need to launch features securely and have built a process for doing so, they don’t need to consult each other every time a new feature is built.

Enforcing these two principles allows teams to innovate independently while working toward a shared goal with a united front.

Amazon is run with an emphasis on decentralization and independent decision-making. In practice, that leads to small teams that are run like individual startups within the broader company.

Amazon’s management philosophy can basically be summed up in two parts:

In the third century BC, a Chinese general named Xiang Yu sailed his troops across the Yellow River into enemy territory, where they faced overwhelming odds.

Another general may have tried to motivate his men through inspirational words or by promising them eternal glory and riches. Xian Yu did one better. He burned his men’s ships and smashed their cooking pots. That drastically narrowed the set of options facing his men: They could win or they could die. They won.

Evolution is a function of environmental change. An early-stage startup is in a constant state of crisis — the ships are always burning. This shortens the feedback cycle and allows a company to learn faster. As a company grows bigger, the threat of constant extinction disappears, making it harder to select the traits necessary for long-term survival. When a company has been around for a while, they have cash in the bank and a buffer against environmental change. But if they remain complacent, the world catches up and the company goes extinct.

They turn into dodos or dinosaurs, in a process that Darwin described in On the Origin of Species:

To build a platform for your team, you have to design for change, and often times that means setting your ships, or security blanket, on fire.

Without the ability to burn the ships and course-correct, even the most successful forfeit their hard-earned advantages and enter decline. Just look at IBM. By evaluating team members primarily on the basis of profit, IBM optimized for the short term and failed to internalize the longer-term potential for external change and disruption.

In the 1950s and ’60s, IBM was the most famous company in the world, having successfully transitioned from manufacturing tabulating machines to producing integrated mainframes.

But decades of success calcified into a bureaucratic management culture in which even small decisions required lengthy audits and endless processes. This approach of “playing it safe” served IBM well when it came to selling $20 million mainframes to large Fortune 500 companies in the mainframe business. But it unwittingly created a top-down management culture that stifled decision-making with red tape.

This led to the company’s near extinction with the rise of the personal computer. Even though IBM developed one of the first PCs, the company’s management was run by people used to selling mainframes. Instead of burning their ships, they overextended the mainframe business, pouring billions into new factories.

In 1993, the company was forced to make the first round of layoffs in the company’s history, cutting loose nearly 60,000 employees. By then, it was too late, and IBM was displaced by Intel and Microsoft. Rather than adapting to the times, IBM created a class of professional managers who emphasized quarterly profits over ideas. This crippled IBM’s ability to innovate.

If you spend all of your time trying to determine exactly what your culture is, you won’t get anywhere, because culture is constantly changing. Empty platitudes like “our culture is about putting the customer first” treats culture statically, when in fact it changes constantly. As a company grows, these words lose their meaning.

If you try to set culture from the top, you’ll add process but stifle innovation. Twitter failed to build a software platform because it tried to overdetermine how third-party developers were interacting with the service, first by cannibalizing their products and ultimately by closing off API access to their product. If you overdetermine culture, you end up creating layers of bureaucracy that cripple your team’s ability to adapt and change.

When you’re building a platform for your team, your people are your platform. Rather than forcing a “right way of doing things,” give people building blocks. Cultural values should be memorable and underdetermined, meaning they’re fluid and adaptable. That allows your people to reinterpret culture in new and surprising ways to meet new circumstances.

This elevates team members and gives them a starting point where they can actually take a value like “embrace change” and live it.

Alibaba’s cultural building blocks aren’t specific values or virtues possessed by fictional Chinese characters. They’re the sense of purpose created by these artifacts. While one of Alibaba’s six values can change, you can bet that throughout the history of Alibaba that the Six Vein Spirit Sword will remain. In doing so, Alibaba leaves its culture underdetermined — and able to change.

Once a culture is developed and embedded, it’s very difficult to change. Uber is perhaps the best-known example of this among startups today.

Under Travis Kalanick, the company’s culture of “toe-stepping” and “always be hustling” served the company as it rapidly grew from a black-car service in San Francisco to a global ride-hailing company operating in 600 cities around the world. While these values were helpful for getting the company to where it is today, it also explicitly determined the type of culture the company would have — making it extremely hard to shift gears today.

The company’s values included:

Uber’s business model depended on its ability to rapidly roll out technology developed in San Francisco and build network effects in new local markets. Uber’s culture promoted aggressive problem-solving and autonomous decision-making by team members. This allowed the company to adapt from the bottom up from city to city.

The downside was that these values determined not just results but how those results were achieved as well, promoting a cutthroat culture that prioritized growth above all else.

Last year, a series of scandals shook Uber to its core:

None of these events are isolated, nor can they be blamed solely on Kalanick. But as CEO, he set the tone and the precedent for acceptable behavior at the company. Even worse, this behavior determined Uber’s reputation and the way people perceived its brand.

When Lyft was founded, it flew in the face of regulations and let unvetted drivers pick up random people off the street. By this time, Uber was working with the government to establish guidelines for ridesharing.

As Brad Stone writes in his book The Upstarts, “It must have seemed unfair to Kalanick that Lyft had the better reputation, even though in some ways it was the more aggressive player.” The cost of overdetermining culture is that it’s extremely hard to change afterward, both internally and externally.

It’s a cost Uber will deal with for years to come. Cracks in your culture when you’re small will seem insignificant, but they compound over time like technical debt and will be much harder to fix down the line.

Related posts:

Those trees on the far horizon tall, forbidding, solemn, solid evidence of time and life, perseverance and survival — they whisper with sawdust tongues, inviting us to explore their mysteries the…

You have realized the potential of InventHub and know that it could be a game changer for your development process, but you just don’t know how to convey how helpful it is to your team lead and…