Functional areas and their team leads follow our Principles of decision making. This section describes more specific ways in which decisions usually happen.
Generally speaking, we try to push decision-making as close to where the action happens as possible. This means that most decisions are made by individuals without requiring a consultation with specific leaders in the organization.
For decisions that primarily affect their area and no others, team leads are empowered to make decisions within their own team without requiring consent from team members of other areas. However, they should make decisions transparently and inclusively, especially if they think another area will be interested in the decision.
They are also empowered to delegate scoped decision-making authority to others at 2i2c.
There are a few kinds of decisions that require discussion and agreement from our team leads:
Decisions with significant financial impact across 2i2c
Decisions that will significantly impact our capacity or commit ourselves to more work
Decisions that have major strategic implications for 2i2c
In these cases, follow How team leads make decisions.
Updating the team compass#
Team leads are expected to routinely update the Team Compass to reflect and updated plans, policies, and systems in their area.
How team leads make decisions#
Team leads often make decisions that impact the entire organization. Decisions usually begin with a proposal in the form of a Google Doc or a GitHub issue, and discussion around that proposal tends to happen asynchronously or in our Organizational strategy meeting.
This group strives for consensus before moving forward, though makes decisions on a consent-based process.
If team leads are at an impasse and must nonetheless move forward, the
Executive Director may break ties.
How area teams make decisions#
Most teams follow a similar decision-making process to the one described for team leads. They may have less formal structure around the process, or modified structure that adapts to their workflow. For example, here’s the engineering team’s Pull Request process.
If decisions within a team are at an impasse, then a team lead can make a decision in order to move forward.