Context

During batch 4, we identified several challenges with how we currently make decisions throughout the organizations. Gathering insights and feedback from multiple people from multiple places, the followings are the main ones we are facing right now:

1. Small decisions take a long time to close

Up to now, we’ve been leaning towards a consensus approach to decision making. While this is great to hear from everyone’s opinions, not every single decision is worth a discussion. This leads to proposals for improvements taking a long time to close and therefore be fixed. This creates frustration for the team, and especially the person who creates the proposals. In some cases, the person even had to chase up the decision makers for final approvals.

2. While some important decisions were closed without us hearing from everyone

On the contrary, we also encountered cases where the exec team discussed and closed important decisions without first hearing opinions from the teams. While we are always happy to discuss when everyone raises objections, this makes people feel unheard and not invited to participate.

3. Team members don’t know to whom to bring up the problems

We experienced inter-AOR issues that would require collaboration and sign-off from multiple AORs. Given our lack of documentation on the decision making process, it’s hard to know who to bring up the problems and who would have a final call on it.

Decision makers

Unlike hierarchical organizations where most decisions are closed by managers or executives, at LDSA, we believe that decisions should be made by the one with the most expertise and with most visibility about the issues.

Let’s go through different types of decisions we have and who would be responsible for closing them.

1. AOR-specific decisions

Each AOR has a clear and defined list of responsibilities as outlined here (If you feel your AOR’s responsibilities are not clear, please let the exec team know as it’s our job to make sure they are crystal clear).

Any decision falls under these responsibilities should be closed by AOR Lead, or an AOR member with most visibility on the matter. These are the people with the most expertise in the area, and who are the closest to the day-to-day operations. It’s the exec team’s responsibility to choose the best person for the AORs. So once they are onboarded, we trust that they would make the best decisions, and there is no need to have the executive team sign-off on the AOR-specific decisions.

2. Inter-AOR decisions

For any decisions that involve more than one AOR, they should be closed and have sign-off by the AORs involved.

First, the Leads of involved AORs should first discuss with each other to reach a conclusion. By exchanging information and discussing the trade-offs, most of the cases, decisions will be reached between the AORs. Only in the case that decisions cannot be reached through consensus, the exec team is responsible to resolve the disputes.

Let’s use an example that we had previously. This year, we need to decide whether we should and can have the Portal Grading for Prep Course. Below was what happened to demonstrate how it would look in practical terms.

1. Prep Course Lead wanted to know whether we can implement Grading Portal for Prep Course and improve the learning experience for students, and she reached out to Dev-Ops team
2. Dev-Ops Lead mentioned that given the short timeline and the ongoing project with the Portal, it’d be a stretch and preferably we should delay it for next year.
3. Dev-Ops Lead suggested an idea that we can instead create another reporting system to record people’s grade and statuses. Which can still solve the same problems without allocating too much resources for the Prep Course.
4. Both Prep Course Lead & Dev-Ops Lead agree with the solution.

3. Rest of decisions

For any decisions that do not already fall into existing AORs, the exec team is responsible for making those. In case the same type of decisions keep on appearing, the exec team will consider the option of creating a new AOR to be responsible for it.

Apart from that, the exec team is also responsible for Organization-wide decisions including:

• Defining AORs including creation or removal of them
• Deciding which courses will be given
• For each course deciding:
• How much they will cost
• When they will occur
• How many people will be in them
• What are the conditions for acceptance (including defining initiatives and mechanisms like quotas to enforce them)
• Under what conditions people may be removed from the course
• Resolving disputes that cannot be resolved by an AOR Lead, or between multiple AOR Leads
• Deciding on how things are communicated to the outside world for the cases in which it is not already clearly defined
• Resolving formal complaints of misconducts from both students, instructors and the community

Decision making process

Now that the decision makers are defined, the next question is how we can balance between efficiency and participation. On one spectrum, the AOR Leads and Exec team close decisions like a bulldozer and will miss out useful insights and sharing from the rest of members. On the other end of the spectrum, for everyone’s decision, we will ask and wait for feedback from everyone.

We want neither of those, and want to create a decision making process where everyone is aware and is encouraged to participate. On the other hand, decisions can be closed without other participation.

Before diving into how the decision making process is like, let’s go through first different types of stakeholders, what’s expected of them and whether they will block decisions.

Types of stakeholders

1. Approvers

The person(s) who have the final say to close the decision. Without them, decisions will be blocked. If you have proposed a suggestion but haven’t heard feedback from the AOR Lead for 2 weeks, they might have missed it so make sure to ping them.

Example: A proposal to change the current QA process won’t go through unless QA Lead is onboard with it.

2. Reviewers

The person(s) whose input is expected, but if they don’t participate, decisions can and should be closed Example: Teaching Lead proposes a set of strategic goals and objectives for the next batch. The exec team can provide input and request changes if needed. However, if they don’t, Teaching Lead can still close decision.

3. Informed

The person(s) who should be aware of the decision as they’re likely to be affected. They don’t block decisions, or are not expected to give input (though if they want, they definitely can) Example: The exec team decides to keep 50 scholarship slots for this batch. While Marketing Lead is not expected to provide input, the Lead should be kept informed as it will affect our marketing content.

Definition of decision

As every single task can be technically interpreted as a “decision”, let’s first define what types of decisions are applicable here.

A decision should follow this process if there’s at least one “YES” for the two questions below: Does this decision need to be approved by someone else, not me nor my AOR members? Will this decision impact other AOR or the entire organization, and they should know about it?

Case 1: Answer is NO to both questions.

This is when you can close the decision yourself and the rest of the organization don’t need to know about it.

Example: If Marketing Lead was to write up a Social Media post, she has total power to decide on that, and there’s no need to triage with other AORs nor the exec team. It also wouldn’t affect other AORs.

Case 2: Answer is YES to at least one question

Example 1: The exec team needs to decide how many slots we will have for this batch. This is the decision that will affect many AORs such as Student Success, Admissions, Dev-Ops. Therefore, this should definitely go to an issue.

Example 2: The Marketing & Communication team receives a request for collaboration with an third-party organization. Since this decision falls under Partnership and requires triage between AORs, this should also go to an issue.

Example 3: QA team decides to extend the QA timeline for 3 weeks. This would impacts the Teaching team as instructors now will need to submit SLU earlier.

Case 3: Answer is YES to both questions.

Example: Marketing team needs to know whether we will have the Side-car Academy for the next batch in order to promote it. This decision should be an issue as it’d require a decision from the exec team and that would affect the entire organization.

Process

1. Create a Github issue for every decision

Once the issue is created, there will be a Slack notification on #wiki-issue-notifications. This is so that everyone can be aware and keep an eye out on decisions that are relevant to them.

For team-wide decisions that require input from the whole team, the wiki issue should exist in the wiki page and be opened for at least a week. This is so that everyone has enough time to review and provide with their feedback.

In addition, such important proposals deserve another ping on #announcements channel as some people might not check the wiki page often.

2. Identify under which AOR the decision would fall

While it’d be obvious in most cases, there will be some issues that it’d be unclear such as this one. The following steps should help to decide the responsible AORs:

Go through the list of responsibilities of each AOR and see which AOR it would best fit If it’s still not obvious, drop a comment asking help from Documentation AOR and the Lead will help with the assignation to the accurate AOR If it’s still not obvious, assign to the Executive Team, who would be responsible for any decision that doesn’t belong to the existing AORs

3. Tag and mention the involved stakeholders

As mentioned earlier, for an issue to be closed, there will need to be at least the Approvers. Typically this will be the AOR Lead or the Exec team, so it’d be important to first identify which AOR the decisions will fall into (previous step).

Depending on the topics, input might be required from the Reviewers, who also needs to be tagged in the issue. Also, when someone is tagged on a GitHub issue, it should be very clear what is that person’s role. Just tagging stakeholders won’t make it clear what is expected from them on that issue

Finally, inform the Involved once the decisions have been made so they are aware of the outcomes. In the case of structural decisions that will affect the entire Organization, all members should have the role of the Reviewers instead of the Involved. The implication is that everyone should be aware and can participate in the discussions early. For this type of decisions, we should share it on #announcements channel and bring it to people’s attention, as the issue can easily be missed.

4. Document the decisions

Decisions once made should be incorporated into the Wiki, which is our single source of truth. Without proper documentation, we can totally forget that certain decisions have been made and kept on discussing the same problem. We should try to document the decisions together with the reasoning. When the reasoning is no longer relevant, we should consider changing/updating our decisions.

5. Commit and embrace the outcomes

Once the decision is made and is documented, we should all commit to following and embracing it. One great example of this is Github issues. Once we decided to create an issue for every single decision, we have been living up to it very well.

Of course there will be days when we might forget. If you see that happened to other people, give them a gentle nudge so we can remind ourselves and each other.

Breaking the rules

Now we have a proper decision making process and defined decision makers. That doesn’t mean that every single decision can only proceed once it goes through this process. Below we explore 2 types of scenarios where we can and should break the rules

Quick wins

There will be quick wins and easy improvements that we can decide quickly to improve our organization and students’ experience.

Imagine, you have an idea of creating a pet channel to share pet photos to increase students’ engagement. Or if you want to implement a Bot to remind people to introduce themselves (aka Shame Bott created by Rui). There are two possible scenarios that can happen. First one is that that doesn’t work out, meaning nobody posts anything there, we will remove it in the worst case scenario. Second one, which is more likely, is that everyone would benefit from your ideas. As an organization, we’d be much better off to move fast with ideas and experiments.

So ask yourself, what would be the worst case scenario if I decide to pursue this idea or experiment? If the answer is trivial, then go ahead and do it!

If a decision is reversible and has little consequences, we should act on it quickly. So that we as an organization can be nimble and act quickly on improvements and great suggestions, especially when those are obvious.

Emergencies

While the following should not happen at all, there can be cases where decisions need to be closed urgently and waiting for answers/feedback from issues is not possible. In these cases, you can and should close the decisions. The worst thing is nobody takes action at all, so please feel empowered to make the call.

After you have closed the decisions, this is what should happen next: Create an issue outlining the decisions made, and the reasoning behind your call Tag either the decision makers or reviewers for them to be aware Add learnings and suggestions to avoid this situation from happening

Regarding step (3), it can be a post-mortem where things went wrong and there is a flaw in our system. However, it can also be an opportunity to set up policy for future cases.

To exemplify the second case, let’s take an example that Chi (exec team) needs to talk with the rest of the Exec team (Catarina & Minh) to urgently approve a budget for our website domain that will expire that day, which costs €20. A suggestion would be to create a policy where any exec member can approve any expenses that cost less than €50 without consulting opinion from the exec team.