Decision Making

We make lots of decisions every day at work, big and small. This article describes core principles of decision-making that we strive to follow in all our teams.

Decisions within specific tasks

We encourage developers to be proactive and make most of the decisions within their responsibility area. If you're working on some task and encountered a problem, we expect that you try to find the solution yourself as the first step. That said, you can always ask for help from teammates - discussions are very welcome.

Team leads are responsible for top-level technical decisions and overall project architecture. Product managers are responsible for the business strategy of the product. For some decisions, you may need to talk to them. But in any case, if you can suggest possible solutions for the problem in question, that would be very much appreciated.

Decisions that affect the whole team

Some decisions have an impact on all team members. For example, it can be decisions on the team's key technologies, code style rules, task workflows, agreements about team collaboration tools, meetings schedule, etc. Here's how we make such decisions:

If the team quickly reaches a consensus (i.e., everyone agrees on what to do), the decision can be made immediately.

If some team members disagree, and the question is important enough to continue the discussion, then we use the following procedure:

1. The author writes down the proposal, including "what" and "why," the pros and cons, and which alternatives they considered. It must be written in a document that the whole team can see, leave their comments, and upvote or downvote the proposal;
2. The team should be given enough time (a week minimum) to study the proposal and the alternatives, ask their questions, and eventually openly vote for or against the proposal;
3. The proposal is approved if the majority of team members vote for it. If the team consists of an even number of people and votes have been distributed equally, then the proposal is approved if the team lead votes for it;
4. The team lead has a veto right for any decisions made this way. They can exercise this right only after all team members have been heard and voted for or against the proposal, and they must be given enough time to do so (a week minimum);
5. If the team lead votes against the proposal during the discussion, it doesn't mean that they have already exercised their veto right. It could mean that they do not support the idea at the moment, but if most team members support it, they may change their mind;
6. If the proposal was declined, it could be discussed again, but not earlier than after two months if team membership hasn't changed. If team membership has changed, the team lead can approve a re-discussion earlier than two months.