Decision Making

At work, we make lots of decisions, big and small. This article describes our core decision-making principles. All our teams strive to follow these principles.

Decisions within specific tasks

We encourage developers to be proactive. Developers should be making most of the decisions that lie within their area of responsibility. If you're working on a task and encounter a problem, we expect that, first, you try to find the solution yourself. That said, you can always ask your teammates for help ─ discussion is always welcome.

Team leads are responsible for top-level technical decisions and overall project architecture. Product managers are responsible for the product's business strategy. Some decisions might require you to talk to a lead or PM. But even in these cases, the possible solutions that you suggest will be very much appreciated.

Decisions that affect the whole team

Some decisions impact all team members. High-impact decisions include decisions about a team's key technologies, code-style rules, task workflows, team-collaboration tools, meeting schedules, etc.

For such cases, here's how we make decisions:

If the team quickly reaches a consensus (i.e., everyone agrees about what to do), we can make the decision immediately.

If some team members disagree, and if the question is important enough for continued discussion, then we use the following procedure:

1. The author writes the proposal down, including info about the "what" and the "why," the pros and cons, and a list of considered alternatives. The proposal must be written in a place where the whole team can see, comment, and vote;
2. The team should be given enough time to study the proposal and its alternatives. They should ask their questions, and eventually openly vote for or against the proposal. For most proposals, the team should decide within a week. If the proposal is urgent, or on the contrary, requires more time to study, the team lead can specify an exact time frame about when the decision must be made;
3. Members vote. A majority approves the proposal. In case of a tie, the team lead is the tie-breaker.
4. The team lead can veto any decision made this way. They can exercise veto rights only after all team members have been heard and have voted for or against the proposal. And members must be given enough to vote and discuss, as mentioned in 2.;
5. If the team lead votes against the proposal during the discussion, it doesn't mean that they've already vetoed it. They might not support the idea at the moment, but if most team members support it, they could change their mind;
6. If the proposal is declined, it can be discussed again, but not earlier than two months before the first vote. If team membership has changed, the team lead can approve a re-discussion earlier than two months.