The Dapper Way

Small Teams
Small Features
Fast
Generous
Close to the Customer
Choice & Fun
Word is Bond
Growth & Learning

We aim to build great products that bring value, while enjoying the process,
even having fun doing so. As our team grows, it is critical that we are in sync
as to how we are achieving this goal. We also want to build the foundation of
an outstanding engineering outfit.

These principles are the result of what we have learned works while at
Dapper. We believe they will help us continue to thrive in the future.
Small Teams
Our goal is to build products, not manage people. A team
should be small, independent, heterogenous, and focused.
Two quick facts:

(1) In a company, as you triple the number of employees, their productivity drops by
half

(2) In a city, as the working population in a given area doubles, productivity goes up by
20%.

This is what we are up against. This is the writing on the wall. Growing like typical big
companies, in a pyramid like structure, means we will lose productivity. Growing
organically, as cities and other complex scale free networks grow, we may even end up
gaining productivity.

So how can we structure ourselves to work like a city? How big should each
“neighborhood” be?

Say the number of people that are assigned to work on an independent project (which
is composed of multiple, dependent features) is N. We then ask, what is the optimal
number of teams we should break this group into, and what will be the average team
size, x?

We assume the number of connections/dependencies/coordination points required is a

linear sum of the number of intra-team connections and of the number of inter-team
connections:
N
x(x−1) (N
x −1)
f (x) = 2 + x
2
√
The minimum of f (x) is achieved then for x = N.

This means that even if we have 49 people working simultaneously on the same
project, the optimal individual team size should be just 7. In reality, though, seldom
would we have a single, inter-dependent project that employs as many as 10 people.
As such, for most projects, the optimal team size should be 2 or 3 people strong.
Teams could grow to be as big as 5-6 people for projects that span a single team.

Each team would be like the A Team, comprised of heterogenous members with
different skills. An example of that is a 3 member team with a front-end engineer and 2
back-end engineers, or a 2 member team with an algorithms person and a systems
person. We will also mix members with different level of experience, so we will not have
teams that are composed entirety of new people.

Sometime, shit happens. A sneaky bug from an old code base raises its head, or an
urgent business need rises. At each sprint, one of the teams will be the “bug
squashing” team, and it will be this team’s responsibility to handle ALL bugs that come
up in the system. Obviously, that might be a tall order, especially in cases where bugs
span parts of the system the team members are not familiar with. Nonetheless, it will
be that team’s responsibility to do its best to handle as much of the bug work it can,
before reaching out to other teams for help. This methodology stresses the need for
quality releases, which do not require other teams to follow your trail and pick up your
slack. The “release” of the bug squashing team will be to close all of the bugs that
were assigned to it along the course of the sprint. In a similar manner to a feature
release, only then, will that team’s sprint will end.

My belief is that over time, this methodology will create social pressure that will reduce
the extent of what economists call “externalities”. In our context, an externality is
someone else having to spend sixteen hours chasing a bug you left carelessly in your
code. Do it too often, and someone from the “bug squashing” team will eventually
come knocking at your door. In fact, we will want to start tracking bugs as related to a
certain feature release, in a similar manner to the way we track a commit to be related
to a certain ticket. In that way, we will be able to understand the true cost of a feature,
rather than just its upfront cost.

In our experience, the number of bugs or issues related to a feature tend to decay
exponentially with time. As such, we will push hard for releasing features a day or two
prior to the end of the sprint (which effectively means the right size of a feature should
be 8-9 team work days, not 10) so the team will have time to address any major bugs
that are found as part of the release process. The feature team will also use this time to
run the upcoming “bug squashing” team through a review of the new feature and its
corresponding code changes.

(1) (cf. http://bit.ly/glzkU3)

(2) (chart: http://bit.ly/eqATeG)

Metcalfe’s Law and project teams

Keep the team as small as possible. Metcalfe’s Law, that “the value of a communication system grows at
approximately the square of the number of users of the system,” has a corollary when it comes to project teams:
The efficiency of the team is approximately the inverse of the square of the number of members in the team. I’m
beginning to think three people is optimal for a 1.0 product release...Start out by reducing the number of people you
plan to add to the team, and then reduce some more.
–Marc Hedlund, entrepreneur-in-residence at O’Reilly Media
Small Features
Any task can be broken down into smaller bits. We define a
feature as an atom of business value that can be completed
within a sprint’s length.
So, our teams will be small, comprised of 3 awesome people on average. How should
we task those teams with building products?

In our experience, it typically takes around two weeks for 3 people to deliver a
valuable, tangible feature. Therefore, we define our sprints to be two weeks long. We
understand that for some features, a sprint may take somewhat less or more time than
two weeks.

The requirement that we build our planning so that every feature’s scope can fit into the
length of a sprint comfortably is a strong requirement and we need to be very diligent
in adhering to it. Accurate planning, scoping and realistic estimation are key to meeting
this requirement, and we will actively measure how good we are at meeting our own
expectations.

When we plan, it is important to be mindful of the dependencies between the different

teams. In general, working in parallel will get you to the finish line faster, but will require
more resources due to the need to mock dependencies and communicate
continuously. Working in sequence or in a staggered model will cost less, but will push
the deadline further back. Finding the right balance between the two is an art, which
we hope to master.

If we find ourselves in a stressed situation, where we’re frantically scrambling to finish a

feature to meet the sprint release deadline, it means we did a poor job scoping and
planning the feature. In the Israeli army, there’s a saying: “If you got a medal, someone
screwed up.” The same is true for Mountain Dew-fueled, all-nighter sessions to get to
the finish line.

We are modeling our team structure on a network of autonomous, connected agents,

rather than a hierarchical tree. To enable releases to span multiple teams, information
should flow without friction.

For each feature/release, we will have the clear release makefile graph that outlines the
dependencies among the teams responsible for the release and the different features.
For each feature, we will have an owner who is responsible for the feature’s
development, coordination and release. That owner will be responsible also to make
sure everyone involved in building the feature are constantly in sync.
Fast
Fast doesn’t mean sloppy or shallow. Fast means a finished
feature that brings value to a customer immediately, rather
than sitting on the SVN shelf collecting dust.
To do that, we will work with short sprints, and build a
“production immune system” that will allow us to release
early and often.
The release process is an integral part of the feature development and sprint scope.
Until a feature has been tested in production and the production immune system has
“accepted” it, the feature is not “released” and the team that built it cannot move on to
new features.

Fast is not about the lines of code per day, or the number of user stories you checked
off. It’s about seeing a feature from inception through to graduation, when it provides
someone with value. You own every feature you’re working on. It’s your baby. If it
doesn’t graduate you should be worried, feel pain, get mad. We are spending roughly a
third of our lives with these babies. They are our godlike creations. We should care
about their destiny.

The quality of our work is measured by how clean and bug-free it is, not by how big the
feature was.

To enable fast releases we will deploy a combination of processes, methodologies and

products. Not only will we have continuous integration and deployment, we will also
build a “production immune system” — a fast, mostly automated, semi-sentient
system. It would release good features into the light of day, while returning bad
features for another round.

To be effective, this “immune system” has to go by the business meaning of “value”. It

has to understand the business implications of a new behavior, and determine if that
behavior is good or bad for our customers.

The cornerstone of the “production immune system” is visibility. We are extending the
concept of “Test Driven Development” to “Metric Driven Development” or MDD. We will
ask for each feature if it is “well-covered” from a metric perspective. Did we include
instrumentation in our workload planning, just like we are including time for writing
tests today? Are we exposing these metrics in a legible manner for anyone to see?
Generous
As a team, we use two main currencies: social clout and
time. A major part of our success thus far came from all of
us being generous with both.
Clout

A great team functions as a meritocracy, where the smartest idea is the one
implemented, regardless of who came up with it. A good friend of mine called it “a
room full of idiots,” where even though everyone on the team is brilliant, you get the
feeling people encourage you to speak up as “we are stupid too.”

This notion of checking egos at the door and openly speaking your mind is very
powerful, but also very fragile. When you have little clout and street cred, if you are new
to the team, or young, it could be hard to criticize the top dog, unless you are
encouraged actively to do so. So it is the responsibility of the senior people in the room
(starting with me) to create an atmosphere where anyone feels welcomed to present his
ideas and everyone embraces criticism. The more clout you have, the more you need
to be generous sharing it with people that still have less.

This does not mean that our discussions will necessarily be polite, victorian-style
debates. We should feel passionate about our ideas and our work. But we should be
open minded to actually listen to what other people are saying, regardless of who
those people are

Time

Yes, we are busy. Yes, we have a lot on our plates. But the difference between a team
and a group of people is that when a team member needs your help, you happily help
him, even if it eats some of your time. This “no problem” attitude is what really binds us
together as a team. There are several things we will do to encourage and sustain this
team spirit:

1. We will not hire jerks (or jerk wannabes), even if they are very talented jerks.

2. In our sprint planning, we will take into account potential cross team assistance
requirements

3. We will NEVER grade or measure anyone’s performance based on any single

deadline or sprint.
Close to the Customer
To build quality products, we need to understand what
problems are we solving, and for whom. To do that, we
work close to our customers. We meet them frequently,
listen to them, and eventually figure out what they need
before they know it.
What we build are products that fulfill complex tasks with grace and delight. These are
not some twitter clients or coupons sites. Trying to do that without thoroughly
understanding the customer is like shooting darts, blind folded, into a redbull can. Here
are a set of questions you need to know the answer to, to say you know the customer:

1.What’s her name? She has a name. Even when we build APIs, some H2O based
creature will eventually use or gain benefit from it. Who is she? Is she part of our
team? Part of another team? A partner? A business customer? And no, most likely,
her name is not Carol.

2.What problem in her life are we trying to solve? Are we making her life easier? Are we
allowing her to do something she couldn’t before? In what way?

3.What impact will the feature we are currently working on have on her life? Will it save
her an hour a week? Generate another $50/hour for her? Make her boss think she’s a
hero?

4.Why are we interested in her? Why is she important to us, as a team, and as a
business? Is she going to be more loyal to us? Is she going to buy more with us?

5.What will she want next? And then? What will she want 6 months from now? A year
from now?

When someone else defines a project, a feature, or a requirement that he would like
you to work on, he will have to make sure he also articulates good answers to these
questions. Ideally, you will be able to interact directly with the customers, allowing you
to gain insights first hand.

Many times, in large companies, people use the word “alignment.” You’ll hear it much
less in start-ups. That’s because in start-ups, alignment comes naturally. Everyone
know who the customer is and what problem we are trying to solve. In my book,
alignment means we all have similar answers to the first four questions above, and will
happily argue with one another on the right answer for the fifth.
Choice & Fun
For us, real fun is not just playing foosball or Space Invaders
(though that can be fun too). Fun is working on something
we feel passionate about, and seeing it through. Passion
comes from choice. Our goal is to maximize each of our
teams’ control over what they work on.
We all make choices every day. Western society celebrates our freedom to choose. We
are working in one of the most intellectually demanding professions a person can
pursue. One of the professions where passion and interest are key to overcoming
challenges and solving hard problems. And yet, we are expected, many times, to work
on things because someone else said so. I believe this doesn’t make much sense.
Each of us should be able to choose, from the set of problems we have in front of us,
those that we feel most passionate about and best suited to solve.

My mission in life is to put in front of you interesting problems that are worthy of your
passion and that you will have fun working on. Yours is to engage with these problems
and come back with shining solutions that we can all feel proud of. Now, that doesn’t
mean that we won’t be working on many tasks and features which are not that exciting.
We will. (e.g. I seldom meet a person that is excited about squashing bugs. They are
typically worth their weight in gold if you happen to find one.) But the integral of
excitement, fun and choice should be always positive.

Sometimes, though, each of us has his own idea he is passionate about. Many times,
this idea is not in our roadmap, or it’s buried way down there. As such, we will be
mandating a policy that will allow a person, or a team, to choose a project once or
twice a year and spend a sprint making it happen. Think of it as our version of
“staycation.” We will take those projects seriously, and they will be reviewed and
celebrated by your peers and potentially be sponsored for further development, if
proven successful.
Word is Bond
The products we build are not a “nice to have.” They are
important and meaningful. We take our commitments
seriously. We should master the art of estimation and build a
realistic view of what’s possible. And then, we should keep
our word.
Keeping our word is critical for making an impact and gaining street cred. Our word is
our worth. That means that we should treat it with utmost respect. We will not
distribute commitments lightly, and we will socialize every commitment we make,
before we make it, among our team members, and then track to it. Commitments
should be telescopic. We should be able to commit to an exact date for an upcoming
feature, and for an exact sprint for a feature planned for the mid-term future. Anything
that is longer than few months forward should be considered lower priority, in which
case we can share our current priorities, or our forecasted release time, but we would
not commit to an exact release date.

The other side of commitments is transparency. Very often, our mid- or long-term
roadmap may change. We may decide to push back features to later times, or give
them a higher priority. We need to understand that these decisions have externalities.
They impact other people. We should bring that impact into our consideration, and
when we are making a change, we need to communicate it, in a transparent fashion,
early and often, so our customers and partners can adapt.
Growth and Learning
We have worked in other places in the past, and we may
work in other places in the future. To gain the most and
contribute the most, we should view every day as a growth
opportunity. We should embrace mentors and encourage
cross-pollination to increase the opportunity for learning and
growth.
As we all know, in this post-modern era, learning doesn’t end when we graduate from
school. We are expected to grow and evolve throughout our career. Technologies
come and go on the Internet in unprecedented rate. Thankfully, we are all surrounded
with amazing people that we can learn a lot from. To facilitate these interactions, we
will try out two things. First, each one of us should find himself a mentor. A mentor
should be someone that you regard as your senior, someone you can learn from and
have good chemistry with. A mentor need not be necessarily from our group, but it will
be an official appointment, agreed upon by you, your chosen mentor and your
manager. You two will meet as frequently as is useful for the both of you, but a mentor
will be expected to meet with his apprentices at least once a month.

The second thing we are going to do to encourage growth will be to mix things up.
Each of us has his own perspective and outlook. Each of us can bring a fresh view to a
solution or a system. To encourage that, we will cap the amount of time a certain team
works together, and periodically change the projects teams work on. Doing these
permutations will require a certain overhead of getting to know each other and the new
project, so we would not want to do it every sprint, but we most definitely would like to
do it once a quarter, and sometimes, if the features require it, more often than that.
The Purpose of This Document
This document is not the Torah. It’s not carved in stone. Its
purpose is to raise the main issues of building an excellent
team to the surface, get us all thinking about them, and
allow us to experiment, conjecture and adapt our
methodologies.
Most importantly, we will learn together what best fits us
rather than some ideal team. We will try and push ourselves,
but won’t be shy about failed experiments and changing
course. In fact, we will make it mandatory to review our
practices and processes at least once a quarter and spend
time and resources adapting and improving them.
I am aware that some naysayers will be skeptical about our
ability to follow some of the suggested methodologies
above, or claim that they are wasteful.
I believe we can prove them wrong, and that in the long run,
we will gain a lot from going in these directions.
I am very proud to be part of this team. We have achieved
some great things together, and will do much more in the
future.

Eran Shir
The Cheat Sheet - Rules of the Game
Small Teams

1. A team will typically be 2-3 people strong

2. Teams will be heterogeneous - both in experience and expertise
3. Teams will stay together at most 3 months. A person will work on the same project
at most 3 months

Small Features

1.A feature should be scoped so that it can be released by a team within a sprint’s
length and bring value to a customer.
2.Sprint’s length will typically be two weeks, and in rarer cases one or three weeks.
3.Heroes and all-nighters are a result of poor scoping
4.Bugs should be tracked to the feature release that introduced them, and we will track
in that way the release’s real cost.
5.We should be aware of dependencies and find the balance between parallel, quick
and costly, and sequential, slow and cheap.
6.For each feature and release, outline the dependencies makefile graph
7.For each feature and release, choose an owner

Fast

1.Velocity=1/(time from last checkin to production deployment)

2.A team is responsible for a feature until it is released.
3.A feature is released when it is being used by someone in production.
4.Metrics Driven Development (MDD) - Every feature should be ‘covered’ well with
metrics that are visible and legible.
5.We will deploy a ‘production immune system’ that will help us improve our velocity.
This system will be based on the visibility we achieve through MDD
6.We will have a revolving ‘bug squashing’ team that will be responsible for all open
bugs.
7.Features will be released the latest a day before the end of the sprint, so a feature
should be scoped to require up to nine team work days.
8.As part of the release process, the feature team will provide a review to the the
upcoming bug squashing team.
Generous

1. The best idea wins, regardless of its origin

2. The more clout you have, the more you need to be generous sharing it with people
that still have less

3. when a team member needs your help, you happily help him, even if it eats some of
your time

4. We will not hire jerks (or jerk wannabes), even if they are very talented jerks.

5. In our sprint planning, we will take into account potential cross team assistance
requirements

6. We will NEVER grade or measure anyone’s performance based on any single

deadline or sprint.

Close to the Customer

1.We should always know the answer to the top four customer questions: What’s her
name? What’s her problem? What’s the feature’s impact? Why is she interesting?
2.We should all try to have an opinion regarding the fifth question: What will she want/
need next?

Choice and Fun

1.Each team will choose the features to work on, out of the available set, based on its
passion and their fit.
2.Each member/team will have an opportunity, once or twice a year, to spend a sprint
implementing a project/feature that is not part of the regular roadmap or priorities.

Word is Bond

1.Realistic estimation and scoping is a critical expertise that we will measure and
continuously improve.
2.Commitments should be telescopic.
3.As we adapt our plans, we should take into account the external impact we cause,
and be transparent with our peers/partners/customers as early as possible

Growth and Learning

1.Each of us will have a mentor that can help her grow.

2.We will mix the teams and change projects at least once a quarter