Once a company starts to grow, it gets harder for developers to get to know each other. But without some kind of compatibility between how people on the team make decisions, things get chaotic, quickly.

The problem starts to show up between teams, when it takes way too many meetings to get systems built by the same company to talk to each other. Or there's culture shock when people move between teams, which leads to less movement. That makes this problem even worse. Soon, meetings become arguments. People can't even understand the position of the person across the table because they're starting from different fundamental assumptions. And nothing spawns useless, frustrating meetings than arguments between people who, deep down, believe different things.

What's the solution?

There are a few ways to solve this problem. Management could dictate how decisions must be made. "You will use Java to solve all problems." "Every team will communicate using JSON." This works, but at a cost -- every decision you take away from someone removes a reason you hired that person to begin with. Besides, you don't need everyone to make the same decision, you need compatible decision-making.

Maintaining a strong culture is often a better option. But "culture," within a company, has a fuzzy meaning. Maybe it's how you hire (which, in the worst case, means "we hire people like ourselves.") It could mean Whiskey Fridays, or Ping-Pong in the lunchroom, or just about anything else you could say about a company. It has something to do with improving shared decision-making. But that's often buried under everything else that falls under the category of "culture."

Context and Taste

There's one specific part of culture, though, that has a strong impact on how people make decisions. I think I first saw the idea in Netflix's culture deck, where they refer to it as "Context" (starting on slide 79).

Context is about creating shared understanding. It's about agreeing on things that we, as a team, typically value. It's about sharing our assumptions, and what's behind them. It's being open about our priorities and goals. It's about building a framework for making good, compatible decisions, without dictating the decision from the top down.

GitHub used a similar concept Kyle Neath called "taste." Here's how he describes it:

I’d argue that an organization’s taste is defined by the process and style in which they make design decisions. What features belong in our product? Which prototype feels better? Do we need more iterations, or is this good enough? Are these questions answered by tools? By a process? By a person? Those answers are the essence of taste. In other words, an organization’s taste is the way the organization makes design decisions.


To help capture taste, Kyle borrowed an idea from Python, and defined GitHub's "Zen" -- that is, a short list of statements that answer the question, "Why did you do that?" This is what he came up with:

  • Responsive is better than fast.
  • It’s not fully shipped until it’s fast.
  • Anything added dilutes everything else.
  • Practicality beats purity.
  • Approachable is better than simple.
  • Mind your words, they are important.
  • Speak like a human.
  • Half measures are as bad as nothing at all.
  • Encourage flow.
  • Non-blocking is better than blocking.
  • Favor focus over features.
  • Avoid administrative distraction.
  • Design for failure.
  • Keep it logically awesome.

Bringing it back to Avvo

To us, this seemed like a great way of capturing some of the core things we, as a dev team, fundamentally value. Some part of our context, or taste. Here's the newest version of what we came up with:

  • Invest in yourself and your tools
  • Defend the user
  • Your teammate’s problems are your problems
  • Attack the noise
  • Take ownership
  • Leave code better than you found it
  • Favor convention over reinvention
  • Explicit is better than implicit
  • Understand why
  • Prove it
  • Keep moving forward
  • Deliver business value

And, like GitHub, ours now exist in a git repository -- ready for updates, pull requests, and comments.

Once you have these values written down, it's amazing where they pop up. During disagreements, it's helpful to tie positions back to these values. In interviews, it's interesting to see how candidates' responses relate to these. They come up during feedback, in meetings, and in 1:1s. They immediately tell people outside of Avvo how compatible they'll be with the kind of decisions we make. And all of these are clear enough that they can inform good decisions, without enforcing a specific decision.

At Avvo, our development team is growing to the size where people can't know everything that's going on. Through ideas like this, we're beginning to define what it means to be a developer at Avvo. It's an opportunity that only comes around a few times in a company's lifetime! If that sounds exciting to you, and you'd like to help us shape this team, get in touch -- through either our careers page or a simple email to me. I'd love to hear from you.