Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decision-making process for our team #2267

Closed
alanna opened this issue Jul 23, 2019 · 3 comments

Comments

@alanna
Copy link
Contributor

commented Jul 23, 2019

Context

In our recent team workshop, we said we wanted to improve our decision-making processes and clarify outcomes.

People said we rehash the same conversations because decisions aren't properly concluded, that they don't know when or how to give input sometimes, and that it's not always clear who actually should have the final say on a given decision. We have extra challenges with this because our team is distributed and we're never all in the same meeting.

Proposal

I am a huge decision-making nerd and I love highly structured processes. But I don't think that approach is right for this team, which is very dynamic, spontaneous, and autonomous.

So, I recommend we use a lightweight version of the Advice Process.

In brief, the advice process is:

Any person can make any decision after seeking advice from 1) everyone who will be meaningfully affected, and 2) people with expertise in the matter.

The decision-maker is clear, and it's their responsibility to make the relevant people aware a decision is underway, gather input, make the decision, and inform everyone of the outcome.

Some key points:

  • If a decision is small and you have a lot of expertise about it, sometimes that means you can just consult yourself and then go ahead. Autonomy is important because we are a high-trust team and we each have our own spheres of expertise.
  • You don't have to consult everyone on every decision. Getting good at determining when to just go ahead and when to consult is a skill we will build and improve as a team.
  • Having this decision-making framework will help us ask the right questions, like "Do I need to consult others who will be affected or have expertise? How can I gather input?" and "I have made a decision. How do I let others know?"
  • Just because you notice an issue doesn't mean you have to be the decision-maker. You can raise it with the team and request someone else take it on. If you think the wrong person is decision-maker for an issue, you can bring that up.
  • It's up to the decision-maker whether to accept a given piece of feedback or not. They don't need to integrate everyone's opinions, only hear and consider them.

I suggest we adopt these practices:

  • Small decisions you take on your own don't need to be formally documented, unless you want to let everyone know. If something is clearly in your sphere and it's low-risk, just go for it.
  • Larger decisions should be documented. Let's use GitHub issues with a decision tag. This will give others a chance to have input and know a decision is happening.
  • Even if you're pretty sure you already know the answer, raising a decision issue can be an effective way to get everyone on the same page so the outcome is known and accepted later.
  • The decision-maker should be the one assigned to the issue, so we know who it is.
  • It's the decision-maker's responsibility to conclude the decision clearly and close the issue.
  • If a decision emerges out of an ongoing discussion (like a GitHub issue on another topic), notice it and bring it into the process.
  • Decisions can be re-opened later if things change.

Actions

Let's use this decision, "What should our decision-making process be?" as the first test case. I will be the decision-maker. Now is the time to have input.

Please read this article: Decision Making (Reinventing Organizations Wiki), to give us a shared understanding and vocabulary about this kind of decision-making.

@alanna alanna self-assigned this Jul 23, 2019
@Betree

This comment has been minimized.

Copy link
Member

commented Jul 23, 2019

I agree with the entire proposal. Using Github issues with the assigned person being the decision maker is a clear process. It's not to far from the way we work today so there should be no cost for the team to adapt.

What's still unclear to me is how we decide who's the decision maker. It's usually pretty easy to know for "ground" decisions. For example, choosing between Figma or Adobe XD would impact the way engineering team work so it should be consulted but the decision clearly belongs to a designer.

It's more difficult when it comes to more high-level, more general decisions. I'll take #2213 as a example of such case. Some of you may feel that this issue should not be opened because it's rehashing the same discussion about terminology but this is not the point here, I'm taking that as an example because of the subject.

Technically I'm the one who's going to implement it, yet I don't feel legitimate to take this decision: it's about UX and terminology, I'm neither a designer nor a native English speaker. Also there are multiple people with strong opinions on this issue.

In such cases, how do we decide who's the decision maker?

@alanna

This comment has been minimized.

Copy link
Contributor Author

commented Jul 25, 2019

Good question @Betree - in the example you mentioned, I think the most important thing is to actually just pick a decision maker and go with it, even if there's no clear right answer, because ambiguity and rehashing can be more expensive than taking a 'wrong' decision when it's pretty low-risk, as in this case. If it's a high-risk, unchangeable decision, then we should be a lot more careful.

If we had the advice process implemented already in the lead-up to the issue you mentioned, I would say that I had taken ownership of the terminology clarification project, and therefore I was the decision-maker. I gathered a lot of team input for the outcomes to that decision, and documented the decisions we made.

But when do we revisit decisions? @xdamman felt we had learned more and therefore should review the decision, while I felt it was too early and we were changing course mid-stream.

If @xdamman wanted to do another round of decision making about terminology, he could launch a new decision with himself as decision-maker, define the scope, gather input, and document the outcome. However, I would hope he'd take on board feedback from the team about whether it was the right time for that, if he was the right person, or if it was a priority.

He feels he's the expert in UX and product issues, but in advice process, while experts should be consulted and listened to, they aren't always the decision-maker. Then again, just because I am the one most bothered by ambiguous terminology, or I'm the one who brought it up first, or am a native English speaker, doesn't mean I should necessarily be the decision-maker either.

There isn't a right answer. But here are the things I can say for sure:

  • Going against what a decision-maker concluded and the agreed process damages leadership and trust in the team overall, even if you are "right".
  • Decisions should not stay written in stone forever - we need to get good at knowing when the right time to rethink a decision has come. Both too early and too late are bad.
  • The skill of deciding who the decision-maker is is a huge part of getting good at advice process - it's not automatic and we'll have to work on it together.
  • It's often better to settle on a clear decision-maker and clear decision rather than staying with ambiguity, even if the final decision is less than optimal in itself.
  • We should regularly reflect on times when we picked the wrong decision maker or the wrong timing and how we can improve, and times when it went well.
@richport

This comment has been minimized.

Copy link

commented Sep 19, 2019

Alllv Gucci

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.