Chapter 9. Bootstrapping Culture

When you are in the role of senior engineering leader, part of your job is to set the culture of your function. A common failing of first-time CTOs is to underestimate the importance of being clear and thoughtful about the culture of the engineering team. Whether you are growing a new team or reforming an existing team, neglecting the team culture is a sure-fire way to make your job harder. As the team grows and evolves, it’s important to attend to your culture as you would attend to any other important piece of infrastructure that you rely on.

At Rent the Runway, I had the opportunity to set up many of the cultural elements of the engineering team. Because the team was still running on the classic, unstructured “scrappy startup” model when I joined, I was able to introduce many cultural structures and practices to both the team and its members. This process was a great learning experience for me.

For many people who are attracted to startup culture, the ideas of “structure” and “process” are seen as pointless at best and harmful at worst. I have seen surveys of startup teams in which the idea of introducing structure evoked such reactions as “slow” and “innovation-crushing.” These respondents believed structure is the reason large companies move slowly, foster bureaucracy, and are generally boring places for bright people to work.

When talking about structure with skeptics, I try to reframe the discussion. Instead of talking about structure, I talk about learning. Instead of talking about process, I talk about transparency. We don’t set up systems because structure and process have inherent value. We do it because we want to learn from our successes and our mistakes, and to share those successes and encode the lessons we learn from failures in a transparent way. This learning and sharing is how organizations become more stable and more scalable over time.

I’m hoping to help you develop a personal philosophy on company culture in addition to giving you ways to set up process and structure. If you want to create healthy teams, you need to have a sense of what is important to you, to your company, and to your growing group of colleagues. Consider not only what you care about, but also how you can scale that knowledge and effort effectively as the company and team grows and evolves. You’re going to be trying out structures and processes and learning from them, but it’s hard to learn if you don’t have a basic theory to test, and you don’t set out to prove or disprove hypotheses about that theory. So let’s approach this culture-creating exercise scientifically, and see how you can think about the pieces of culture you might need in a logical fashion.

Early startups attract people who are capable of dealing with extremely high amounts of uncertainty and risk in exchange for equally high degrees of freedom to operate. There is no long-term guarantee that the company will succeed or even continue to exist for very long, no matter how strong the idea seems on paper. Often the market is unproven. Some signs look good and other signs look bad. There may be fierce competition from other companies, big and small. Furthermore, there is very little established work to build on. The code is unwritten. The business rules are not set up. It is hard to overstate how many decisions need to be made in the context of a startup, even one that has been growing for a couple of years. Everything from deciding on technology frameworks to deciding on office decorations is up for grabs.

Many of these initial decisions will be undone a couple of times before they settle. It’s easy to think about changing a framework that didn’t scale well with the company’s technology needs, but things like vacation policy, core office hours, and even company values could change and evolve in a startup’s first few years.

The most important thing for leaders to be willing to do in those early days — and leaders generally includes everyone in the company, not just the founders or executives — is to pick a strategy and run with it. Cultivate decisiveness in the face of a massive number of options. You have a problem? Figure out a solution and fix it. That solution doesn’t work? Try something else. You don’t need to find the perfect solution; you need to find something that will get you through to the next milestone, whether that milestone is the next release, the next growth spurt, the next funding round, or the next hire.

Sometimes companies decide to limit the decisions themselves, as in an organization that foregoes titles. Having no titles is in one sense a decision, but in another sense it’s a decision that means you never need to decide what someone’s title will be, you won’t need to worry about promoting people to new titles, and you don’t need to build up the apparatus that will make future decisions about titles because you have removed that as an option. Deciding not to decide right now is a popular option for new companies, because it really doesn’t matter at the scale of a few people.

One of the greatest writings about organizational politics is a piece called “The Tyranny of Structurelessness” by Jo Freeman. While the article is about early feminist/anarchist collectives, Freeman’s insights apply equally well to startup culture. Pretending to lack structure tends to create hidden power structures resulting from the nature of human communication and the challenges of trying to scale that communication. Interestingly, Freeman describes a set of circumstances in which the unstructured group can, in fact, work:

It is task oriented. Its function is very narrow and very specific, like putting on a conference or putting out a newspaper. It is the task that basically structures the group. The task determines what needs to be done and when it needs to be done. It provides a guide by which people can judge their actions and make plans for future activity.

It is relatively small and homogeneous. Homogeneity is necessary to insure that participants have a “common language” for interaction. People from widely different backgrounds may provide richness to a consciousness-raising group where each can learn from the others’ experience, but too great a diversity among members of a task-oriented group means only that they continually misunderstand each other. Such diverse people interpret words and actions differently. They have different expectations about each other’s behavior and judge the results according to different criteria. If everyone knows everyone else well enough to understand the nuances, they can be accommodated. Usually, they only lead to confusion and endless hours spent straightening out conflicts no one ever thought would arise.

There is a high degree of communication. Information must be passed on to everyone, opinions checked, work divided up, and participation assured in the relevant decisions. This is only possible if the group is small and people practically live together for the most crucial phases of the task. Needless to say, the number of interactions necessary to involve everybody increases geometrically with the number of participants. This inevitably limits group participants to about five, or excludes some from some of the decisions. Successful groups can be as large as 10 or 15, but only when they are in fact composed of several smaller subgroups which perform specific parts of the task, and whose members overlap with each other so that knowledge of what the different subgroups are doing can be passed around easily.

There is a low degree of skill specialization. Not everyone has to be able to do everything, but everything must be able to be done by more than one person. Thus no one is indispensable. To a certain extent, people become interchangeable parts.

Here Freeman describes a common scenario for many early-stage startups. Even when the overall company grows beyond the small group, the engineering team often pushes itself to stay unstructured. Hiring “full stack” engineers who are exclusively sourced from the professional and social networks of the current team results in low skill specialization and high homogeneity. Forcing the team to be collocated lowers communication barriers. And perhaps most critically, having an engineering team that operates solely as the execution arm of the product or founder makes the team highly task-oriented.

I will hazard a guess that some folks may bristle at this characterization of the common startup technology organization. After all, these engineering teams are often the well-paid darlings of the company! Be that as it may, the unstructured organization either displays characteristics that ultimately make it less self-directed than the members might wish to believe, or is run by hidden hierarchies and power dynamics. In many cases both things are true to some extent.

The example of the structureless team also applies to technical decisions and processes. There is a reason that you often find a lot of spaghetti code in early startups. When work is done to satisfy an immediate task, in a unified code base worked on by a team of interchangeables, the result is not usually a larger thoughtful structure, but a tweak here, a hack there — anything to get things done and moving forward. It’s no surprise that we usually end up refactoring spaghetti code when we want to make it scalable, because refactoring usually involves identifying and explicitly drawing out structure in order to make the code base easier to read and work in.

That, in short, is the value of structure. Structure is how we scale, diversify, and take on more complex long-term tasks. We do it to our software, we do it to our teams, and we do it to our processes. In the same way that strong technical systems designers are capable of identifying and shaping underlying system structures, strong leaders are capable of identifying and shaping underlying team structures and dynamics, and doing so in a way that supports the long-term goals of the team and equips the individuals to achieve their best.

Nothing is more ridiculous than a small team with a rigid hierarchy. We would all think that a team of five people where the fifth reported to the fourth, who reported to the third, who reported to the second, who reported to the first was pretty strange and probably unnecessary. Similarly, if a team of five in a struggling business spent most of their time in meetings deciding which toilet paper to stock in the bathroom, their priorities would seem skewed. Structure can come too early, and cause harm by slowing down a group that should be focused on other things.

However, it’s more common in small companies to see structure come too late. The problems creep up slowly. One person gets used to making all of the decisions and changing his mind frequently. This strategy works fine when it’s just him and a couple of others. But when he keeps doing it with a team of 10, a team of 20, a team of 50, what you start to see is a high degree of confusion and wasted effort. The cost to change his mind becomes more and more expensive.

One of the best analogies I’ve heard for startup leadership comes from a friend, On Freud, who’s been in engineering management at several different startups. On describes the earliest startup as like driving a race car. You’re close to the ground, and you feel every move you make. You have control, you can turn quickly, you feel like things are moving fast. Of course, you’re also at risk of crashing at any moment, but you only take yourself down if you do. As you grow, you graduate to a commercial flight. You’re farther from the ground, and more people’s lives depend on you, so you need to consider your movements more carefully, but you still feel in control and can turn the plane relatively quickly. Finally, you graduate to a spaceship, where you can’t make quick moves and the course is set long in advance, but you’re capable of going very far and taking tons of people along for the ride.