I originally wrote this memo to add to the onboarding flow of a previous company.

This is a draft of the unspoken assumptions we use for team decision making and work prioritization. Its goal is to help new people joining the company to understand how, and why, we do what we do and how, and why, we make certain decisions.

Decision Making

How do we come to decisions as a team? This is how we look at it:

• Speed - We tend to favor solutions that can be implemented faster than solutions that take longer.
• Complexity - We tend to favor less complex solutions over more complex solutions. How do we define complexity? Generally, if we have two solutions that are similar, but one of them has to touch two services (let's say two new Amazon Web Services we haven't used previously) and the other solution is a script somewhere (let's say the script would live on an existing server that we're already supporting) then we would probably favor the latter solution since it has only one touch-point (a script on an existing server) over the former solution that has two touch-points (we'd have to configure two new services to make it work).
• Testing - We favor easier to test solutions.

• Cost - Similar to complexity, if we can find a solution that gets us most of the way there (say 80-90%) and we don't have to change much to do it, we should seriously consider that solution first.

  An example of this would be using DNS's round-robin support over adding a separate load balancer. Sure, the DNS solution isn't fully-featured, but it would get us 80% of the functionality of the load balancer and all we'd need to do is add some IP addresses to the DNS configuration, which has a way lower implementation and maintenance cost than adding and supporting an entirely separate load balancer.

Work Prioritization

How do we prioritize work? What criteria do we use? Generally, we try to iterate on our solutions.

For example, when we upgraded from python2 to python3, we broke the upgrade down into multiple discreet parts and then scheduled them when we had room over the course of nearly two years.

We first changed our environment to use python virtual environments instead of a global python installation so we had more isolation and flexibility with the python version we were using. Then we updated each external library to python3 compatible versions. Then we upgraded the underlying operating system to the latest version. And only after all that did we actually upgrade our python version and complete the upgrade.

The easiest way to get a big new initiative started is to break it into discreet parts and work to get each of those parts scheduled. We try and let everyone schedule pet or passion projects in between core functionality that is needed to push the business forward. Passion/pet projects are not only big new initiatives but also things like getting rid of some technical debt, upgrading dependencies, and finally fixing things that are driving people nuts.

Communication

Please don't come into a meeting and complain about how everything is wrong and it all needs to be re-written, that's the surest way to get the entire team to ignore all your current, and possibly future, suggestions.

If you find that meetings are getting heated, or you're thinking things are unfair, it might be because of a definition or unspoken assumption problem. Read this entire document again and decide if the more tenured members of the team are using an unspoken assumption that you're not.

If you do have a different assumption than the rest of the team then we should talk through it and decide which assumption we should move forward with for this specific project, and maybe all future projects also.

If we're all on the same page regarding assumptions, then there might be a definition problem. Different members of the team might have different interpretations of a word's meaning. For example, we had some heated meetings about a solution because the engineer who proposed the solution had a different meaning of the word scaling than the rest of the team. This could've been cleared up by a simple definition check.

Success

We want all team members to succeed here, and not just succeed, but do their best work. We're not trying to optimize for one feature or one product, but for the entire team to to do their best work over months and years, and we've found these unspoken assumptions have helped us accomplish that goal over and over again.