/
The Handbook

The Handbook

Status: LIVE

The Handbook

This is the meta document that explains how 9Y works. Whereas most of the Playbook is structured as a series of small and focused articles each representing a single piece of knowledge, the Handbook is an exception to that.

Reading time: 45-60 minutes. Grab a ☕️ first.

Who are we?

We're 9Y.

Our mission at 9Y is to advance the state-of-the-art of building digital products. 

Our way of doing that, is to put people first. You can call that our core strategy. Almost any decision we make, can be traced back to this belief that if you put people first–and build a place where the best people want to work–that everything else will sort itself out. This belief drives most of our policies. One example of many is our commitment to transparency including publishing our playbook open for the world. We summarise this belief by saying that we put "relentless focus on the people behind the products". This is what defines us. And we think also sets us apart.

Our core values are:

  • people come first: Give trust. Receive it too. Empower. Act as one. But support individuals. The value of this place is the people, not much else.

  • come as you are: Don't leave your identity at home, bring it along. Be brave by being vulnerable. Be a human.

  • strive: Strive to grow as a person. Learn something. Invest in yourself. Cherish results and victories, and celebrate them. Do things with intent. Be formidable. Be someone others can rely on.

  • love exploring the dark: Challenge the status quo. Question truisms. Take risks and enjoy the rewards. Reason from first principles. Think!

  • volunteer kindness: Show empathy. Don't (ab)use your power. Be kind, especially when you don't have to be. Be resolute, but always gently.

Get ready because here comes another bold statement:

We envision to change the world by being the most impactful, trustworthy and effective builder of digital products. And by never relenting our insanity to destroy the status quo in pursuit of innovation.

Sounds insane doesn't it? We've only been around since 2015. However, in that time we've become a core contributor to one of the largest open source software projects in the world. We've published software that is used by millions of people. We've created open source libraries that some of the most innovative companies in the world rely on, including NASA, Google, The New York Times, Bosch, Yahoo, Cisco and Venmo, just to name a few. We've reached over a million developers (not a figure of speech, literally over a million) through contributions on platforms like Stackoverflow and GitHub. We've co-organised conferences. We've spoken at others. We've taught courses at university for many years, educating the next generation. We've helped deliver many, many, projects from all over the world. In fact, chances are good that you have already been touched by our software at one point or another. If you've done any of these then you probably have: made a phone call in the UK, driven through a tunnel in Europe, bought fuel in Europe, bought a train ticket in Austria, rented flexible office space in the US, paid an electricity bill in Germany or Austria, opened a bank account in Austria, bought something second hand in Asia, did an internet search in Russia, found a workman in Africa. That list goes on and on. So, in a way, we might already be able to make the claim that "we've changed the world". As outrageous as that may sound.

Philosophy

Our company requires a proper governance model that allows us to work together well. I'm sure we all agree that the "wild west" approach does not work at scale:

As we grow, this becomes more and more important.

So what's important here? How about:

  • Clearly defined roles & responsibilities.

  • Unambiguous accountability.

  • Core values and ground rules that define common expectations from everyone.

  • Preferably, not too many managers. Instead of having layers of management and having to contend with the Branching Factor problem, can we distribute power and authority in a better way?

  • Decision-makers should be nearby. I don't want to go through endless hops to get to someone who can make an actual decision.

  • Decision-makers should be empowered. I also don't want to need to recruit multiple people to sign off on something, one person would be ideal.

  • A lot of autonomy and freedom to get things done. But in a non-chaotic way.

  • Few rigid boundaries between people. Watch Elon Musk explain this, he does it better than I could (video, link starts at correct place, ~2 minutes long).

  • The people who are deciding over budget, staffing, strategy, should be close to the action. 

  • Processes that are simple and empowering. You want clarity. But you don't want unnecessary TPS reports (video).

  • Asynchronous communication.

  • "Information highways". Information should be easy to access, even if it's curated by people whom you don't directly work with. For example, this could be a dashboard where you can see the information that you need in realtime, without having to go bother someone.

  • High transparency.

  • A culture of trust, and blameless problem solving. So that we can talk about issues directly and honestly, and resolve things quickly. Problems will always arise.

  • Impeccable note-taking and documentation hygiene.

  • Great tools.

  • Work in flexible cross-functional squads by default. For example, a software project should be structured as a single autonomous squad that includes Frontend, Backend, Design, PM and QA. All in the same single squad.

  • Flexibility. We don't to get stuck into "oh we've always done it that way" modes of thinking.

You'll recognise that a lot of our cultural values and operational principles are in service of the above. That's not an accident. It's also why we're investing heavily into in-house tools like Foundation. It's also why we are always trying out new things. How many time tracking tools have you used at 9Y recently? It's not because we're mad. It's because we're trying to build an effective company.

I will say though, that while the goals are easy to list, it's really quite hard to pull this off. Especially as a company scales. It also entails making some hard choices, such as embracing transparency, letting go of traditional budgeting, and taking risks into new directions. But I think that the benefits are so big, that it's worth doing.

Our way (in a nutshell)

Enough philosophy. How is 9Y actually organised?

Quick side-note: if I capitalise a word like Squad or Activity in the middle of a sentence, know that I do it on purpose to refer to a specific definition. See 9Y Vocabulary for a list of these special terms.

Activities

In a nutshell, 9Y doesn't have an organisational chart. We also don't have a traditional structure. Instead, we are organised as a bunch of independent, ever-changing, squads. Where each squad has exactly one mission. These squads are interdisciplinary, meaning that designers, project managers, engineers and anyone else who is required to deliver a particular mission, are all in the same squad. These are typically small groups of people, usually less than 6. We call each such mission or project an "Activity". Each Activity has exactly one squad behind it, and that's what we mean when we say "Squad".

Squads

These Squads aren't hierarchical, but they do have rules which distribute decision making power amongst the members of the Squad in a well defined and predictable manner. The Squad is empowered, meaning that the power to make decisions rests within the Squad. The Squad is free to pursue its mission as it sees fit without the need to go ask for approvals. Resources aren't infinite so there may be restrictions to what the Squad can do, but these are specified up front and are known when the Activity is started. These Squads are generally short lived, they only live as long as needed to complete the Activity. You can be part of more than one Squad at a time, though typically you'll only be in 1-2 at any one time.

Once the Activity is completed, the Squad disbands, and members are free to join new Squads to pursue new Activities. We do this for customer projects, but also for internal things like finance or sales. The whole company is organised like this.

Roles, Gameplans and Ground Rules

Every member of a Squad has a role to play. And decisions need to be made. I mentioned that Squads aren't hierarchical, so we need some method of distributing power and responsibility. We do this using "Roles". We have many well-defined Roles at the company, like "Tech Lead", "Project Lead" or "Engineer". And each of these Roles comes with a manifest that describes what the responsibilities and powers of that Role are. Responsibility equals accountability. That means that when you assume a particular Role, that you personally inherit those powers and responsibilities. If the Role definition says that it has power to decide over project budget, and you assume that Role, then you have that power. Not your boss, not the CEO, but you. Power comes from the Role, and only from the Role. You will have a boss, but not in the traditional sense (more on that later). For now know that your boss's power comes from their Role. And that means that they have very specific things that they can and cannot do. That's a key concept to understand.

You might wonder how this translates into an org chart. It doesn't, and we don't have one. Org charts make sense to depict hierarchies but our system is not a hierarchy. More info here: 9Y's way vs Hierarchies

In addition to Roles, we also have Gameplans. You can think of Gameplans as standardised processes. They describe how common but non-obvious situations, that involve multiple people and Roles, should be handled. Gameplans are basically there to avoid confusion and ambiguity. Gameplans are situation specific, for example we have one for when a VIP visits our office, another for when we want to send an invoice to a customer. We try to be very sparing with these. And we only create Gameplans when the natural way of doing things doesn't work, or when there are many different ways of doing things which cause ambiguity.

Ground Rules are similar to Gameplans in that they set out some rules. But they aren't situation dependent. Ground Rules apply to everyone in the whole company equally, at all times, regardless of Role.

Teams and Schools

Squads are short lived and are always changing. So we need something more to make things work well long-term.

There are people in the company who are domain experts in your particular field, and whose job it is to support you in your career. They aren't in your Squad(s) directly working with you on your Activity (=project), but they are there for you in the background. They're a constant as you move between different Squad/Activities, and you will always have them regardless of which Squad you're in. For example, as a software engineer at 9Y, you'll have another engineer looking after you, someone with a lot of experience whom you can learn from and someone who tries to make things better for you. We call this person your "School Leader". Why School? because this role is largely around mentoring and advancing your single discipline within the company (by discipline I mean: engineering, design, project management, sales, etc.).

There are also people in the company who have an overview of all Squads and make sure that the Squads make sense and that the individual Activities fit in with the overall company vision. Similarly to your School Leader, they are a constant regardless of which Squad you're currently in. They also make sure that you're happy in your Squad(s), and that you are in Squads which you like to be part of. They try to place you in Squads which fit in with where you want your career to go. They also track your performance, and approve your promotions. We call this person your "Team Leader".

We put all School Leaders and Team Leaders together, and call that the Management Team.


Full Guide

The above was the executive summary. Here's the full story...

Overview

At any one time, the company may be undertaking many different Activities (or missions). E.g as a company we may be working on Project X for a customer, as well as twenty other customer projects. We may be pitching to win some new business from a prospect. We may be working on an internal project like Foundation. At 9Y we use the term Activity as a generic term to refer to any one of these things, where "thing" could be any of: a customer project, a pitch, an internal project, the act of moving into a new office, recruiting itself, even management itself can be thought of as an Activity, etc. Really, everything that we do, should be thought of as an Activity.

Most Activities are finite in time but there are some exceptions like "recruiting" or "accounting" which are long-running. An Activity always has a clear mission. As we said, each Activity has a Squad that's responsible for delivering it. At 9Y we don't have departments like "the engineering department", "the design department", or "the marketing department". Rather, you should think of our Squads as temporary goal-specific task forces, that are assembled dynamically solely for the purpose of delivering that Activity, and only that. And the company as a bunch of loosely related Squads.

Squads can be assembled from anyone in the company, even external people. You can think of a Squad as a task force, or a hunting party. Some Squads hunt lions, others hunt bears, and others protect the camp. Once the metaphorical lion is caught, those squad members can join other Squads where their help would be most impactful. That means that I as a person, can be hunting lions one week and protecting the camp next week.

Squads are multi-disiplinary (aka cross-functional). So a single Squad might consist of a backend engineer, a mobile engineer and a designer. Or just three designers. A Squad whose mission is to win a big customer, might need to prepare some design drafts, and provide esimates, and do a big pitch. So this Squad may have people who are good at sales in it, e.g. the CRO, an AE, a Designer and an Engineer. This particular Squad may exist only for 3 days, and once the Activity is completed, it then disbands. Each Activity has a Squad behind it, there is a strict 1-to-1 mapping. Although there is a 1-to-1 mapping, the same groups of people will often work together because similar activities need similar skillsets.

How the members of a Squad work together, and who has what responsibility within the Squad is defined using Roles. That's important to understand. Your job description changes, based on which Activity you're working on, and your responsibilities are scoped to that Activity. That means that your Role is not fixed in the company, it will be different for each Squad that you’re in. Each Role is backed by a very precise manifesto that list the powers and responsibilities that come with that Role. As a member of a Squad, you assume one or more Roles, and your responsibilites and powers are granted to you by the Role. I'll say that again because it's important: your power to make decisions within the company and the responsibitilies and accountabilities that this entails, are based on the Roles you hold, not your job title, or your bosses approval or how many years you've been with the company. I'll get to how this all relates to your job title and compensation in a minute. The important thing to appreciate now, is that you don't have to ask your boss for permission to do things. Your boss is there to assign you your Role(s), to check in with you regularly and see how you're doing, to support you in your growth and development, and to recommend you for a promotion, but nothing more. They are not there to approve your decisions, they cannot block your decisions, they cannot meddle or micromanage, they can't set boundaries, in fact your boss probably isn't even in your Squad. If they are in your Squad, then their power to act within the Squad comes only from the Role they hold in that Squad, not their seniority in the company. This can get interesting, for example you could hold the "Activity Lead" Role in a Squad (that's basically the main leader role for a project, more on that later) and your boss could be in your Squad with the "Engineer" Role – in the context of this project, your boss has to follow your lead and respect your decisions. Feel free to take a sneak peak at some Roles, to see examples of some real roles.

But Roles on their own aren't quite enough. Roles basically only specify *what* someone is empowered to do (and accountable for). Roles don't specify how to do things. Sometimes there's many different ways to skin a cat. Also, Roles don't really explain how interactions to other Roles work. Sometimes it's obvious, but other times it's not. For when it's not obvious, and especially when there are multiple potential ways of doing things, it's important that we standardise on one way of doing things, and that we all know what this one way is. Otherwise you get chaos. We do this using Gameplans. If you think of cooking for a second, as in making a meal. Roles are like ingredients. How the ingredients should be combined is specified in the recipe. Gameplans are like recipes. These Gameplans describe how the people holding specific Roles should organise and interact around typical Activities like developing an app, managing project budgets, customer invoicing, etc.

Sometimes we just want to do something simple. Example: eat an apple. Everyone knows how to do that intuitively without the need for a recipe. In those cases we don't have Gameplans. We try to be sparing with Gameplans and really only introduce them when the natural way of doing things doesn't work out, or when there are many different ways of doing things, and not standardising would cause ambiguity.

Together, the Roles and Gameplans create an emergent mesh that distributes responsibility in a natural way to the right people, and empowers them to get things done.

Here's an analogy to tie it all together. As a company we play a bunch of different games at any one time (Activities), each of these games has players (Squad), each player fills a specific role as required for that particular game (Role) and each game has rules by which it must be played (Gameplan). Real example:

Activity

Basketball

Mission

"Score more points than the other guys."

Squad & Roles

Michael: point guard
James: center
Kobe: shooting guard
Shaquille: small forward
Kevin: power forward

Gameplan

NBA rules

At 9Y, many different games are played at the same time, a few games of basketball, a few football games, even a game of shuffleboard. Back to reality, we don't play basketball at 9Y, so "point guard" isn't a real Role you'll find here. Instead we have Roles like Eng: Engineer, https://9y-media.atlassian.net/wiki/spaces/9RPBK/pages/405438679, EL: Engineering Lead, AL: Activity Lead,