The Handbook

Owned by Luka Mirosevic
Last updated: Feb 08, 2023
39 min read

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:

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, HoP: Head of Product. There are many Roles.

That's basically the 9Y governance model in a nutshell. You can read more about its inspiration and origins here: 9Y's way vs Hierarchies. You can visualise it like this. (NB this diagram says team when it means Squad.)

Roles and Squad

The Roles within a single Squad are decided when that Squad is bootstrapped and typically stay constant throughout that Squad’s life. (There’s a gameplay that lays out how Squads are bootstrapped.) People can have different Roles on different Squad. For example, you can be the Tech Lead on one Squad and an Engineer on another Squad. "Tech Lead" and "Engineer" are well defined Roles, which carry with them a list of responsibilities that you inherit when you assume that Role within the context of that Squad. When we assemble a Squad, we do so to deliver an Activity, and we try to match the particularities and challenges of that Activity to the right people who are best suited to solving that. We might also take other considerations into account, e.g. someone who has expressed that they would like to transition from being a developer to becoming a manager, may be given the chance to try out being an Activity Lead on an upcoming customer project.

At 9Y, these Squad are non-hierarchical. I'll illustrate with a diagram: the left is what we do, the right is what we emphatically don't do.

What implications does this have?

  • Within each Squad, there is no fixed structure.

  • Every Activity (e.g. project) has an AL: Activity Lead, who is ultimately responsible for delivering it. Basically the DRI (Directly Responsible Individual).

  • The PM is not always the Activity Lead. What's the difference? See Activity Lead vs PM.

  • The Squad can be assembled exactly as needed for the Activity to match skill sets and resources. For example, in the diagram above, I'm illustrating a software project, that is quite heavy on design so we have two designers. It's also quite heavy on backend engineering so we have two backend engineers.

  • Anyone can assume the Role of Activity Lead, Tech Lead and Design Lead. The above is an example of a software projects. But we have other kinds of Activities. So the roles involved in the Activity can be very flexible. For example the "ongoing accounting" Activity involves the CEO and HoF. The "Customer acquisition" (i.e. sales) Activity includes the CRO, one or more AEs, the HoP and potentially a PM, Eng and Des too. That's the beauty of this system, we can organise around Activities in the best and most natural way possible, and do so in a clear and cohesive way.

  • The Activity Lead is in contact with every Squad member, and all Squad members are in contact with each other too. This is reflected in who attends meetings, that we have a single Slack channel for each Activity/Squad, a single Shared Drive, etc. This also implies full transparency within an Activity, even with information that other companies may typically consider sensitive, like budgets, true costs, true timelines, etc. – this is a good thing.

  • Engineers and Designers work in the same Squad alongside each other, same goes for the other disciplines. That doesn't mean that they work for the same amount of time. It does however mean that there are no barriers, and that Designers can ask Engineers for input, and vice versa, whenever they want to.

  • The Activity Lead doesn't devolve into the one-and-only messaging bus in the Squad through whom all communication must go. Anyone can talk to anyone. However, the Activity Lead should always be kept informed about key discussions so that they can effectively lead the project forward. The Activity Lead should also propagate key information to the other Squad members.

  • In a deeply technical project, say where the customer may be a software developer themselves, then an engineer could assume the Activity Lead role. If that makes sense for the project, then our system affords us the flexibility to do so. Though while each customer project must have a PM in the Squad for things like budgeting and invoicing, the project ownership responsibility can be extracted from the PM and given to someone else, if that's what would best serve the project. Another example would be a design heavy project say for a marketing agency, where a Designer can be the Activity Lead.

  • Part-time project membership is possible. An Engineer could for example be working half-time on project A and half-time on project B. Another common case is one where an Engineer is working 80% on some project, and has 20% time reserved for helping the Sales Team with estimations and offering. These are natural constellations within a company that we often want to have, and our organisational system supports them natively.

  • Because the flat structure implies that everyone communicates with everyone, there is a natural force to try and keep these Squads small. We prefer small Squads at 9Y. There are other reasons why we prefer smaller Squad: software development is generally a big-brain, not so much a many-brains problem. Amdahl's Law, and the Law of Diminishing Returns also describe quite well some of the dynamics of big squads that make them suck. Sometimes, bigger squads are necessary, and we support those too, and these are best though of as squads of Squads, i.e. a constellation of Squads working together towards a common goal. And the interactions between such Squads are encoded in the Gameplans. I wrote a bit more onSmall Squads.

  • Everyone talking to everyone does not mean that there is no leader. We should all give input, but ultimately we want to converge on a single decision and get organised. We rely on the Activity Lead to facilitate this. Our Ground Rules are in service of making this easier.

A few more words on this flat hierarchy within Project Squads. At 9Y, a PM is not considered a superior to an Engineer. Project Managers, Engineers, Designers and QAs are all on the same level. This may be unusual compared to other companies. Why do we do this? Building good software is really quite hard. A key part of it boils down to information management, specifically to the sources of information available within a project. A PM is a great source of information–they speak to the customer, they have a great overview of the budget, they work every day to improve their skills in effective communication, priority management, customer management, documentation, requirement writing, etc. Software engineers also have their craft, no need to explain. Here's what I think that many companies miss: in addition to an Engineer's undeniable value of actually writing code, software engineers are an equally great *source of information*. They know the platforms that they're developing for better than anyone, they are in the trenches writing code and know the risks and complexities of the project's actual codebase, they understand security, and architecture, and performance, they're closer to the action and they have a more sober view of timelines. This applies analogously to the Designer and QA too. So both the PM, Engineer, Designer and QA are equally rich and important sources of information. So I think it's silly to design an information flow hierarchy (which is basically what a team structure is) in which equally important sources of information are above and below each other. That just implicitly promotes one source of information as more important than another. Which is backwards because as we just said they're all key for a successful project. In my opinion, a better design pattern for this is a "circle", where each information source is equally represented. I say information sources, but I mean people. We want these people to work together and build consensus, or at least decisions, as a team. We want high bandwidth discussions and arguments, and balanced decisions. We want decisions to be thoroughly considered, and we want to afford everyone a voice in this process. And that requires mutual trust and appreciation. We want these interactions to be organised and structured, but not in a rigid hierarchical way. Giving a PM explicit authority over an engineer might a) short-circuit the process of mutual trust building and prevent it from happening, and b) is a very tempting escape hatch for the ever-so-busy PM that can be misused to avoid having tough conversations with Engineers and the rest of the Squad. We really need these conversations, because that's where the magic happens, so we don't want such an escape hatch to exist. Sure, the PM often assumes the Role of Activity Lead which brings with it certain powers, but it's important to remember that at 9Y, a PM is never an Engineer's (or Designer's or QA's) boss.

Teams and Schools

Okay 🤔... So I'm in these small mission oriented squads, and when the job is done I join another small squad. But who's my boss? Who's responsible for following my career progress and for my performance reviews? Whom do I go to if I sense frictions? Who writes these Role definitions anyways? And do I have any say over them? And if everything is a finite thing ("Activity" is what you called them), how do meta things like making sure that I have good tools, or that there is a great continuous integration system in place get done? And who is responsible for those? And whom do I talk to about my long term aspirations? And who looks after me and tries to place me into Squads that allow me to grow in those directions?

I'm glad you asked, and you're right, Squads and Roles on their own don't quite cut it, and we need something more. We need some meta-structures in the background. Enter Teams and Schools.

Let me start answering your questions with another question. Imagine you’re an Engineer, who would you rather have as your boss: the best engineer in the company who can best help you level up your skills, or the best operational strategist who will make sure that every project you're involved in is running as smooth as silk? Ideally you want both. This idea is the root of our Schools and Teams concept.

Here comes another analogy. You're a caveman. When we go out hunting lions, we assemble a hunting party and follow the leader who tasks us all with individual roles and makes sure that we're an effective team that doesn't get eaten–this aspect of your job is part of the Team system. When we get back to camp, we sharpen our spears, we work on inventing new weapons, we discuss hunting techniques, and we sit and chat with our mentors–that aspect is part of our School System.

Everyone at 9Y is a member of one Team and one School. Here's some examples:

Person

Team

School

Person

Team

School

Leon the Engineer

Product

Engineering

Luke the Designer

Product

Design

Sabrina the PM

Product

Project Management

Victor the Account Executive

Sales

Sales

Alois the Head of Product

Management

Management

 

Remember, this is in addition to your Roles within Activities/Squads. Teams and Schools are Activity/Squad independent, and focus on long term things. 

Each Team has a leader. Each School also has a leader. And you will have a leader from each. It's possible that the same person is the leader of both your Team and your School, so you'll have a single person fill both leadership roles.

These Team/School leaders are what you would typically think of as "your bosses". So at 9Y, you'll still have a boss. I mentioned the word "boss" before, this is what I've been talking about. But they have significantly less power over you than they would at more typical companies. Remember, they cannot approve your decisions, or block them or tell you what to do. Those powers come from your Roles and Gameplans, and only from there. However:

  • Someone has to allocate Roles and make sure that people who are good at Kotlin end up filling the Eng Role on the Android projects.

  • Someone also has to look out for the person who started life as an engineer, but has a great sense for design and wants to develop in that direction and take on the Des Role on an upcoming project. And we'd prefer for that someone to not be LinkedIn, if you know what I mean.

  • Someone also has to follow you as you execute your duties as laid out by your Roles, and recommend you for a promotion when you reach the next level of proficiency. Or, help you figure out what you're missing if you aren't quite meeting the expectations of your Role.

  • And someone has to arbitrate changes to the Roles and Gameplans over time as we learn better ways of doing things. Are the processes that govern role interactions working well? Do these need improvement?

So if your Team/School leaders aren't in your Squads, how do you interact with them in practice?

  • For some Jobs (e.g. AE and PM), your leader in both systems is the same person. For other Jobs (e.g. Engineer, Designer), you will have two different leaders.

  • A leader of a Team or School holds regular 1::1s with you. If you have two different leaders across your Team and School, then you have two 1::1s, a private one with each. Private means private, so what's discussed in these meetings cannot be shared by your leader to anyone, not even the CEO. Sharing some information may be necessary to drive change, but in that case you have to explictily give permission to what gets shared and how it gets shared. By default it's nothing. 1::1s are sacred at 9Y. Meeting notes from 1::1s aren't allowed to be stored on any 9Y owned system (because an admin could technically override access permissions). More info in the 1::1 Protocol.

  • A Team/School leader holds regular performance reviews with you. If you have two leaders, the performance review is a threesome, and they both decide together with equal weighting. See the Career Preview - Philosophy.

  • Your leader is responsible for your happiness, effectiveness and professional growth.

  • There is an implied accountability. Your leader entrusts you to perform all duties implied by your Role(s), and you are accountable to them that it gets done. You are also expected to keep them informed.

  • Each leader is responsible for driving improvements to the Roles and https://9y-media.atlassian.net/wiki/spaces/9RPBK/pages/405635079 manifestos, for their areas of competency (with general oversight from Management).

Team/School Leaders are Roles, just like any other Role at 9Y. I've summarised some key parts of those Roles in the list above to help explain the concept, but the source of truth is a Role definition. The responsibilities of those Roles are distributed using exactly the same mechanism as all other Roles for Activity/Squads. In fact, being a Team/School Leader is part of an Activity called "Management", whose Squad members hold Roles like https://9y-media.atlassian.net/wiki/spaces/9RPBK/pages/434503822, https://9y-media.atlassian.net/wiki/spaces/9RPBK/pages/431817797, https://9y-media.atlassian.net/wiki/spaces/9RPBK/pages/434438241, etc. 

Team and School leaders are (typically) different people but they both have a common set of responsibilities (MM Role). A Team Leader additionally has the TL Role. A School Leader has the SL Role. In other words:

Teams

Here are some example Teams at 9Y, along with their leaders. 

Product Team

Product Team

HoP

PM

Engineer

Designer

QA

 

Sales Team

Sales Team

CRO

AE

(N.B. These are an example, see https://9y-media.atlassian.net/wiki/spaces/9RPBK/pages/431849991 for the up-to-date roster).

Team leaders are primarily focused on ensuring that day-to-day activities are running smoothly. They worry about things like:

  • Protecting your time/resources. Anyone can request for you to join their Squad, but your Team Leader must approve this and they're responsible for resource scheduling.

  • Does everyone know what their Role is?

  • Do we need external resources to help us finish on time or fill knowledge gaps?

  • Are your colleagues acting professionally and pulling their weight?

  • Is a project (=Activity) in trouble? What do we need to do to fix it?

  • Are we sticking to our rituals like our project debriefs, onboarding process, etc.?

  • ... see the full https://9y-media.atlassian.net/wiki/spaces/9RPBK/pages/431817797 Role definition for the source of truth.

Schools

Here's some Schools at 9Y along with their leaders. 

Engineering School

Engineering School

CTO

Engineer

QA

 

Design School

Design School

HoD

Designer

 

Project Management School

Project Management School

HoP

PM

 

Sales School

Sales School

CRO

AE

(N.B. These are an example, see https://9y-media.atlassian.net/wiki/spaces/9RPBK/pages/431849991 for the up-to-date roster).

School leaders are responsible for general improvement to their discipline. By discipline I mean e.g. design, software engineering, sales, etc.. Both of the people, and of the company on a meta level for that particular discipline. They'll worry about things like:

  • Can I go to this conference?

  • What is our public company reputation with regard to our discipline?

  • What knowledge have we gained, that would be valuable to share with other disciplines? It might be something great to improve collaboration between disciplines (engineering and design is a common one).

  • Are we still happy with React Native, shall we evaluate Flutter? How about XD vs Sketch?

  • Are we moving up the design ladder?

  • Do we have established software engineering practices? Are we following them? Do they need to be updated to reflect the changing landscape? That's an example from the Engineering School, but the same goes for all other Schools, e.g. in the Design School the question might be whether we're following appropriate design practices?

  • What about code reviews, what's our policy for doing them? What about design reviews? Similar for other Schools.

  • ... see the full https://9y-media.atlassian.net/wiki/spaces/9RPBK/pages/434438241 Role definition for the source of truth.

TLDR for Activities, Roles, Gameplans, Teams and Schools

You're part of one or more Squads. Each Squad pursues an Activity. Your power to act within that Squad comes from your Roles, and only those. Your Roles are Squad-specific, so you might have different Roles in different Squads. Gameplans give you helpful structure for how to do common things and how to interact with other people. Additionally, you're part of a Team and School, and their leaders are your bosses. You'll have regular 1::1s with your Team and School leaders. During this time you can talk about improvements, that help you do better as part of your various Squads, as well as about personal matters. You Team leader is good to go to for practical things. Your School leader is really good at your particular craft and you can think of them as your mentor.

See the full and up-to-date https://9y-media.atlassian.net/wiki/spaces/9RPBK/pages/431849991

The Management Team

Who's Management? That's the collection of all of the Team and School leaders. The CEO is the AL of the Management Team, and he has the same responsibilities towards the members of Management, as they all in turn do toward their Team/School members–including 1::1s, performance reviews, etc.

How does the company set direction? The company board proposes high-level, long-term strategies. The CEO then creates a vision and makes a plan to execute this vision. He distills this into a) a draft company roadmap, and b) a set of draft OKRs. These are then presented to Management, whose job it is to challenge and bless the roadmap and OKRs. Once Management is on board, the roadmap and OKRs are ratified. Individual Team/School leaders are assigned OKRs and are in charge of delivering upon them. At this point, the Team/School leaders have autonomy and authority to execute as they see fit. They are free to delegate, are empowered to make decisions (no need to ask for approval). They are also free to assign company budget on their own. The Team leaders act as mini-CEOs within the scope of their missions (as laid out by their OKRs), and are free to do what they want to deliver this mission. They do this by bootstrapping Activities and Squads, and setting goals for those Squads. There may be restrictions imposed by the OKR, but these are on a blacklist basis, i.e. the OKR can impose certain restrictions, but the default is that everything is allowed. Contrast this to a whitelist based approach, where everything is forbidden by default and any powers that are granted must be granted explicitly. The Team/School leaders are highly empowered, but therefore ultimately also highly accountable. Team/School leaders must defend their budget spending and decisions to Management later. It's basically a "trust first, verify later" approach. Management regularly meets up to share on progress and keep in sync, these are the "Management meetings". When placing risky bets, Team/School leaders are encouraged, but not required, to run this by Management first and get buy-in–e.g. before making large spending, or when starting long term or risky programmes. Getting buy-in from Management isn't required if you feel confident that it's the right move, but the advantage of getting buy-in is that it transfers some accountability away from you. The obvious implication of placing risky bets without seeking buy-in, is that if you go rogue too often and you don't deliver results, then you might not last long on the Management Team.

The Team/School leaders basically have total freedom, however they cannot break our values or https://9y-media.atlassian.net/wiki/spaces/9RPBK/pages/405569561. Those apply to everyone equally.

This entire process is transparent across the whole company. From when the draft roadmap and OKRs are created, to when these are discussed and ratified by Management, including all of the regular Management meetings. The OKRs are published in full and visible to all. Anyone is welcome and encouraged to provide feedback. Everyone is also welcome to sit in on Management meetings, either to just listen in, or to actively provide feedback. All meetings will have an open conference link that you can join, and the schedule is published on the company shared calendar. If you want to discuss something slightly bigger, ping the CEO in advance to give you an agenda slot so that we can manage time effectively.

Bootstrapping a Squad

Typically, Team and School leaders will bootstrap Activities and Squads. For example, the Sales Team leader would bootstrap one or more Activities/Squads for pursuing sales strategies. The Engineering School leader might bootstrap an Activity to improve our continuous integration system. But in principle anyone can propose to bootstrap an Activity+Squad. If you experience some friction at work, for example having to use your personal phone and giving your number to customers, which you're not a fan of, you can propose that we bootstrap an Activity to introduce work phones to the company. Maybe other people had a similar problem. Maybe there are other Teams which have different problems that might benefit from a common solution, e.g. the Sales Team might want to be able to make phone calls directly from their sales tool and have them tracked automatically to prospects. If you're not a Team or School leader, then you might not have an OKR which would directly empower you to create an Activity/Squad. But you can still propose one. Just talk to any Team/School leader or to Management, and get someone to sponsor your Activity for you. So feel free to propose an Activity/Squad any time.

There are many channels available to you for proposing this. You can add it to the agenda for an upcoming Townhall. You can tell your Team or School Leader during a 1::1 and recruit them to propose it on your behalf, if it falls within the remit of their OKR they might be able to bootstrap it immediately on the spot. You can sit in on Management meetings and mention it. Proposing the founding of an Activity basically falls under the https://9y-media.atlassian.net/wiki/spaces/9RPBK/pages/405405720, so you can use any of those channels to do it.

Team leaders are responsible for approving their members to join a particular Squad (as per the https://9y-media.atlassian.net/wiki/spaces/9RPBK/pages/431817797  Role). Any Team/School leader is free to found an Activity/Squad if it serves their OKR, but they must first recruit members by going to the other Team Leaders and getting authorisation to use their members. If a Squad will require other resources like money, this will be specified in the OKR. Team leaders can generally make their own decisions for all budget and personell allocations, but they must defend their decisions, and are in turn accountable for these to Management. More on bugdeting below.

For more details on bootstrapping Squads, see the Gameplan on https://9y-media.atlassian.net/wiki/spaces/9RPBK/pages/405373097.

Budgeting

OK, so Management consist of all Teams and School leaders. They agree on company programmes and execution strategies. Team and School leaders have their missions which they must deliver. Additionally, Team leaders own their people's time, and they approve their members joining a Squad. 

What about budgeting? The CEO plans the budget, and allocates it to particular managers. The managers are then free to spend the budget how they want to. If they need more budget, they ask the CEO and get approval. If they don't spend all of their budget, then their budget gets taken away next year. Just kidding, we don't do any of that. It's a horrible way to allocate money. OK yes, the good thing about this is that the CEO (or CFO or whoever) can make a budget plan for the year, and knows when things go wrong. Whoop-de-doo. The disadvantages are:

  • Allocation is done blindly ahead of time

  • Muddy accountability

  • It allows laziness

  • The spender of money doesn't have skin in the game

  • Finance/controlling runs on a fixed cadence, typically on a quarterly or yearly rhythm. But Activities in the company don't really care about how long it takes for the earth to hurl around the sun. Some Activities take less time and can be evaluated more quickly, others take several years and cannot be evaluated within a year. Shoehorning all Activities into an arbitrary controlling schedule is a bit silly in my opinion. So when new information comes to light during a year, it's awkward for management to change plans. Making it awkward for your company to change direction in light of new information is not a good idea, ask Nokia.

  • There is upwards pressure on spending money, as managers want to protect their budgets, this can even become a status symbol

  • The decision to allocate budget and the decision to spend it, are done by different people at different points in time

I would argue that this isn't proper budgeting. If you think about it, it's more like a basic notification system that informs the CEO (or CFO) when his budget predictions went wrong. Like a stop-loss, but not much more. It's also used as a tool for planning hiring, but it's a poor tool for that in my opinion.

So how do we actually do it then? Team and School leaders can spend money at their own behest. They don't have to ask for permission. But, they regularly and thoroughly have to defend their decisions to spend money towards Management. They are responsible for accurate predictions of money spending and providing this to Management so that we can maintain planning security with regard to future spending. They can change these predictions at any time, whenever new information comes to light. Restrictions may be imposed on spending, as part of OKRs, to provide some guard rails. But no money is "allocated" and no budgets are "approved" in advance. Team/School leaders can spend money from their own free will but need to show a ROI on those decisions later. Team/School leaders also set their own timeliness against which the ROI is to be judged, as makes sense for the Activities that they are executing. Team/School leaders are rewarded for achieving their OKRs with minimal money spent.

Finance

We also have a pretty unique system in place for finance. It's a real-time, predictive, activity-based costing system, with a cost allocation DAG, along 2 dimensions: value streams and cashflow. That probably doesn't mean anything to you, but the point is that we're doing something fancy, that enables everyone at the company to see at a glance what costs have flown into delivering an Activity. You can see the actual cost of an engineer's work time, including the cost of the hardware they work on, and the cost of their seat in the office, their partaking in company summits, the AE's sales commission, etc. all the way down the chain. And compare this with the expected revenue of that Activity. You can also blend out certain cost categories to see traditional measures like gross margin, and ignore all the indirect costs, if that's what you prefer. You can also see how these values change over time, for example if we buy a test device for a project, but then later reuse that device on a future project, you can see how that cost gets amortised across the two projects and how the first project's share-of-costs goes down. We run every Activity as its own profit center, and the data flows in realtime. I.e. if an engineer spends 1 hour working on a project, that cost is capitalised in realtime and reflected on the dashboard for that Activity (=project). So PM's have accurate and realtime information regarding their projects' budgets. If a Team/School leader plans to spend 10k EUR on some Activity, they inform Management of this and this spending is then planned, instantly making its cashflow impact visible. There is company-wide transparency on most financials, including all spending and earning, (salary data is one things that is rolled up for confidentiality reasons, see the section on transparency for details). Data for these profit centres is available to everyone in the company and anyone can run their own reports. Our data collection and BI tools allows us to graduate past the basic phase of simply listing all profit centres and showing their revenue and cost at the end of an accounting period. We can go a step further and do sophisticated analyses such as "if I take into account our investment into our continuous integration infrastructure, how did this affect the budgets of projects that came after this change? And what about the effect on deadline hit rates. And NPS scores?". Team/School system leaders should do such analyses in support of their spending. But if someone else feels like we're being silly with our spending, they can access the data themselves and look into it, and hopefully make a case for improvement.

This is really hard to do well, because it requires us to be savvy across all of these dimensions: salaries, acquisition costs, travel expenses, equipment expenses, depreciation, travel, bonuses, customer billables and bad payers, long term investments that have marginal effects, external contributors, deferred tax implications, future cashflow implications, multinational tax system and transfer pricing implications, writedowns, corrections, discounts... The list goes on and on. Calculating this in arrears is already a hornet's nest of complexity. Many companies just do basic "financial accounting" and don't even bother with simple forms of "costing". Advanced companies do costing or even activity based costing, in arrears on a fixed accounting schedule. Doing it in realtime makes it so much harder. Adding on future prediction, as well as the reconciliation that that implies, is on a whole other level still. I would phrase this problem as "seeing how money flows in the company, and making money spending decisions and seeing what the future implications of that decision could be, in realtime, accurately.". Solving this particular problem is one of the most challenging problems we've tackled as a company. And it's never really done, as new cases always come up. I'd say it's in the Top 3, right next to culture and hiring. Our Foundation product is instrumental in solving this problem.

(⚠️ Sidenote: this is an ongoing part of Foundation and not all of it is in production yet. The architecture and design for this is solid, but implementation isn't there yet. I'll delete this sidetone once reality has fully caught up with what's written above.)

Job grades & compensation

Squad

So we've covered that you are part of one of more Squads. And you can take on multiple Roles, even try out new ones that you've never done before. But how does that tie into your job title and compensation? Read on. This part will be pretty standard.

Role

You have one or more "Roles", which might be different across Activities, e.g. Tech Lead on Project X, Engineer on Project Y, and Activity Lead on Project Z. You can have multiple roles on a single Activity/Squad, e.g you could be Tech Lead and Engineer on Project A. As we talked about already.

Job

You have one "Job". This is roughly the School which you belong to, e.g. Engineer. It represents your career path. This is what you're good at. For some Jobs, there are Roles that carry the same name, e.g. there exists an "Engineer" Job and an "Engineer" Role, but they're not the same. During your day-to-day work, you act in accordance with your Role. For example if my Job is "Engineer", I will usually fill either the "Engineer", "Tech Lead" or "Activity Lead" Roles on projects. The keyword is "usually". For example Eva's job is "Engineer", but she sometimes fills the role of "Designer" because she wants to grow in that direction. Peter's Job is "CRO" but he sometimes fills the Role of "CEO", e.g. when Luka had to take a few months personal leave in 2019.

Your Job is like your lane, and you want to get better at this discipline over time. And your Role is what you actually do day-to-day, and is the instrument from which your responsibilities and powers come from. That doesn't mean that if your Job is Engineer, that you will be asked to fill the role of Marketing Analyst. Your Role assignments will typically relate very closely to your Job. The Role system is coherent and clear about the nuances of what exactly your responsibilities are within the company, and how they differ across different projects, and it's the only source of your responsibilities at 9Y.

Job Grade

Each Job is associated with multiple "Grades", and as you get better at your job, you level up across these grades. e.g. level 4. Each grade has a salary range associated with it, and your salary will lie within that range. There is a matrix that describes the formal requirements for each grade, and once you fulfill enough requirements, you level up to the next grade. This happens as part of your performance reviews. Basically a promotion. Your Team Leader and School Leader jointly approve your promotions. Your level is public within the company, and you can see what levels everyone else has.

Job Title

You have one "Job Title", e.g.: Software Engineer.

Compensation

You have a "Compensation", e.g. 2.5k EUR gross/month. As I said already, your job grade will dictate a range for this and your compensation will lie within the range for your grade–there are no exceptions to this. Different jobs may have different compensation types, e.g. someone doing "Sales" may have a commission component as part of their compensation, founders have equity, managers might have a bonus, etc. There are also regional differences, for example all Croatian employees get a customary Christmas bonus ("Bozicnica"), whereas all Austrian employees get 14 salaries ("Urlaubszuschuss" and "Weihnachtsgeld"). We may also be running experiments with compensation, these are usually short lived and if they succeed, they are then rolled out to the whole company, or rolled back. Your compensation is not public information within the company. Keep in mind that your level, and the salary range for your level, are public, so your rough compensation range is defacto public. Management has detailed information about everyone's salaries, including each other's, as well as of the founders. Nobody from the Management Team will disclose your exact salary to someone else.

See the https://9y-media.atlassian.net/wiki/spaces/9RPBK/pages/431653227 . The way to get promoted is to live our culture, executive your Roles well and to hit the requirements for higher levels in the Job Grades Matrix.

The Feedback System (& Transparency)

Transparency

We aim to have a high degree of transparency within our company. It enables good and timely feedback, which is necessary for correcting mistakes. Unfortunately we all make them constantly. Transparency is also a great forcing function for acting in the way you should and want to act, which doesn’t always coincide with what’s convenient at the time. Anything to help "right" win over "convenient" is good.

At 9Y we have these 4 security clearance levels:

  • Board: Everything. Access to some actions such as transferring money, control of our valuable assets like our domain, keys to safes, access to the company security camera, are guarded and these are given on a need-to-have basis. But as far as information access is concerned, this is the master level.

  • Management: Almost everything that the board has access to. The board might have access to some information before the management team gets it, e.g. discussions around investments, acquisitions, founder compensation, profit sharing schemes. But this typically gets passed on to the management team pretty quickly.

  • Core Team: Pretty much everything that management has access to, except for detailed employee salary data. Individual employee salary data is rolled up into aggregates in company wide reports. This is pretty much the only thing that we aren't 100% transparent on as a company; having said that, employees' levels and the applicable salary ranges for those levels very much are transparent, so while we're not 100% transparent on individual salary numbers, we are close.

  • External Team: this one is restricted by default, and access is given on a need-to-know basis

This implies that all channels on Slack, with the exception of the Management and Board channels, should be open to all Core Team members. The same goes for Google Drive.

Feedback

Everyone at 9Y is welcome to provide feedback on anything that they see. Even if they don't have an immediate answer. Just identifying a friction is already helpful.

The Feedback System is a universal system that applies to us all and gives us all equal rights and responsibilities, regardless of our job.

Why have it? It's at the edges of the company (Engineers, Designers and PMs) where the action happens and actual work gets done: where actual customers are spoken with, where our processes are actually executed. But the leaders who design and are responsible for driving improvement to our processes (i.e. the Team and School leaders), are typically one layer removed from the reality of how these actually work out on customers, codebases, designs, etc. It's a bit of a fallacy. The leader's visibility into reality is much poorer than that of their team, but they're the ones tasked with setting direction. In order to not end up like Kodak, Nokia or Yahoo, there needs to be a strong mechanism for information to permeate back to the leaders, quickly. If you don't know, these hugely successful companies died very quickly because they couldn't adapt to the changing reality of digital cameras (Kodak), the invention of the iPhone (Nokia, though there were many other victims here), and the explosive growth of the internet with "search" emerging as the new technology that users preferred for navigating this information (Yahoo). My personal (admittedly outsider) interpretation is that these companies had poor information flow. I'd put money on the fact that there were people at those companies who saw these massive threats, and probably even had good ideas on how to respond to them. But they never got through to the decisionmakers in time. At least not in a way that led to action quickly enough. Assuming that we don't want to die, it's so important that we get this right. A large part of our culture is designed exactly to avoid this problem. We (predictably) call this our "Feedback System". The Feedback System should be used to improve all processes, including the organisational structures of Squads, Roles, Gameplans, Ground Rules, and the School, Team and Management system. The Feedback System should also be used to improve the Feedback System itself.

Feedback isn't just to be directed at Management. You can give feedback to anyone. If you see a colleague doing something particularly great, don't hesitate to tell them.

The https://9y-media.atlassian.net/wiki/spaces/9RPBK/pages/405405720 is described here. But this diagram illustrates the basic idea.

Final Thoughts

We briefly mentioned our https://9y-media.atlassian.net/wiki/spaces/9RPBK/pages/405569561 and Values. These apply to everyone in the company equally, and we are all collectively responsible for adhering to them. The Ground Rules and Values don't recognise any structures. In other words, if you see your leader not sticking to them, then as a member of 9Y, it's your responsibility and right to remind them. If we often find ourselves wanting to act against our Ground Rules, then they may need to change. Use the Feedback System. (NB: The recognition that our Ground Rules may need to change does not mean that they should not be followed, unless we want to have a wild west situation, you should continue to follow the currently accepted rules until the new changes take effect.)

A word on continuous improvement. The social contract and general expectation is that everyone sticks to the principles outlined here. I'll call it the "Handbook". The Handbook only make sense if we all play along. There is a very important nuance here. Yes, you must follow the Handbook. No, you don't have to like the Handbook, and if you see room for improvement, which I'm sure you will, please speak up. That includes when things are incomplete or ambiguous, and especially if you disagree with something or sense friction. Use the https://9y-media.atlassian.net/wiki/spaces/9RPBK/pages/405405720. The Handbook itself is a living thing that will change over time as 9Y grows and gets better. If you feel like there are better ways to do things, then please please please speak up. Improving the state-of-the-art of building digital products is why 9Y exists. Our mission and core values are non-negotiable, everything else is.

What to read next

 

 

Owner

Reviewer