3 ms·

Does anyone have any experience how this might fit inside a company? Getting sign off from peers can be tricky when everyone is busy, but perhaps only a few rev

Does anyone have any experience how this might fit inside a company? Getting sign off from peers can be tricky when everyone is busy, but perhaps only a few reviewers are needed, and as long as everyone is given the opportunity and time frame it sounds like a fair way to move forward with design decisions.

dwr3k1ng 6y ago
I think you can even bring this topic up with an RFC in the format that author mentioned directly and open it for comments. The process can start evolving from there.
tchalla 6y ago
> Getting sign off from peers can be tricky when everyone is busy, but perhaps only a few reviewers are needed, I think, you have kind of answered the question yourself. Personally, I like to group people into three categories : understand, accept and agree. The agree group is the one that you need to get 100% on board. Typically, this is the group that provides you resources (time, money and employees). The accept group is the one that doesn't need to agree but needs to accept the decisions taken. That is, they need to accept the structure in place to make decisions and understand that they are important. The accept group typically are people who are fence sitters and close watchers. They like what they see but do not have to necessarily agree with everything. Finally, the understand group is the ones who do not agree or accept but just understand what's going on. Typically, these people can influence projects outside the working sphere but as long as they understand it; they would not be difficult.
- KineticLensman 6y ago
  The UK military (amongst others) map stakeholders into one of four categories: Responsible, Accountable, Consulted and Informed. (RACI) [0]. Stakeholders tend to sit up and take notice if they think they might be Responsible let alone Accountable for something. Note: the distinction between Responsible and Accountable is really important but not always understood. If a manager puts an untrained employee in charge of something, it is the manager who should be accountable when something bad happens, not the employee. [0] https://en.wikipedia.org/wiki/Responsibility_assignment_matrix https://en.wikipedia.org/wiki/Responsibility_assignment_matr...
- maroonblazer 6y ago
  I do something similar and, depending on which group a given stakeholder falls into, determines how much effort I put into getting their input. For those in the 'agree' group I plan ahead to ensure I can get time with them 'in person' to discuss and debate the proposal in real time. For those in 'accept' I email/post the document and ask for comments/feedback by a specific, reasonable, deadline. If they're too busy to respond then they've forfeited any right to criticize, complain or block the proposal later on. If they provide feedback that I don't implement then I need to have good reasons why I'm not and share that with them. The 'understand' group tends to be upper mgmt who trust me and, so long as I've gotten everyone in the 'agree' group onboard, will support the decision/proposal. This is typically done in a regular 'check in' or via email.
leetrout 6y ago
RFCs are used to great success (IMO) at HashiCorp. See more info at: https://www.hashicorp.com/blog/redesigning-hashicorp-consul-ui https://www.hashicorp.com/blog/redesigning-hashicorp-consul-... https://www.hashicorp.com/resources/closing-keynote-research-as-code https://www.hashicorp.com/resources/closing-keynote-research... Now my personal opinions on the subject: Working at HC it’s really insightful to have the RFCs to review and understand where things came from. At the same time, in my very limited experience there, they were used for gate keeping both on the authoring side and on the review side. Certainly some level of gate keeping is necessary and intended but I hold the opinion today that RFCs could / should be used everywhere and that extra work should be put in to ensure contributions and reviews are fair and welcome. On at least one occasion an RFC had a VP or higher say “no thanks” and then in out-of-band conversations it gets approved. I think I was just too naive and thought decisions and discussions would be very open. Also a couple teams worked without creating RFCs and I don’t think that was healthy, either. That’s the legalistic side of me coming out... if there’s a process for some but not all what are the exemptions and why? Managers would tap some people to write RFCs and would dissuade others. Again, probably to be expected in a large, political org and just something to be aware of if you implement RFCs at your org.
exceptione 6y ago
> Getting sign off from peers can be tricky when everyone is > busy The article mentions that you as the rfc creator ultimately takes the decision how to go forward, and should not seek consensus. from the post: > The process seeks a consent-based environment, not a > consensus-based one. If some people care about a topic a > lot and come up with a written document that explains many > things in detail, everyone can (and should) trust them. > The authors shouldn't wait for everyone's confirmation of > their proposal. When they get enough feedback, they should > be able to continue further with or abandon the idea. It's > their decision. Since they prepared the doc and collected > many comments on it, they can have a better judgment.
gingerlime 6y ago
We use a similar process, inspired by Basecamp[0]. For us it seems like the biggest challenge is getting feedback from the right people. Mostly due to the sheer number of pitches (RFCs, project proposals). And we're a small team. Also it's a bit difficult to decide what goes first and how to make sure we don't bite more than we can chew. Overall I agree with the article that the biggest benefit is from writing things and thinking about them in a structured way. Some ideas sound great, but once you start digging, problems emerge. Being able to pull the brakes even before starting, or refining the idea to a much smaller core is perhaps the most valuable and non-intuitive benefit. [0] https://basecamp.com/shapeup https://basecamp.com/shapeup
lazyant 6y ago
You don't get sign off (approval) from peers but comments from them. It's important the RFC is public and anyone can comment on it. If after a period of time there are no objections expressed in the doc (people are busy etc) then that means the objections were not that important and we can move forward.

dwr3k1ng 6y ago

I think you can even bring this topic up with an RFC in the format that author mentioned directly and open it for comments. The process can start evolving from there.

tchalla 6y ago

> Getting sign off from peers can be tricky when everyone is busy, but perhaps only a few reviewers are needed, I think, you have kind of answered the question yourself. Personally, I like to group people into three categories : understand, accept and agree. The agree group is the one that you need to get 100% on board. Typically, this is the group that provides you resources (time, money and employees). The accept group is the one that doesn't need to agree but needs to accept the decisions taken. That is, they need to accept the structure in place to make decisions and understand that they are important. The accept group typically are people who are fence sitters and close watchers. They like what they see but do not have to necessarily agree with everything. Finally, the understand group is the ones who do not agree or accept but just understand what's going on. Typically, these people can influence projects outside the working sphere but as long as they understand it; they would not be difficult.

KineticLensman 6y ago
The UK military (amongst others) map stakeholders into one of four categories: Responsible, Accountable, Consulted and Informed. (RACI) [0]. Stakeholders tend to sit up and take notice if they think they might be Responsible let alone Accountable for something. Note: the distinction between Responsible and Accountable is really important but not always understood. If a manager puts an untrained employee in charge of something, it is the manager who should be accountable when something bad happens, not the employee. [0] https://en.wikipedia.org/wiki/Responsibility_assignment_matrix https://en.wikipedia.org/wiki/Responsibility_assignment_matr...
maroonblazer 6y ago
I do something similar and, depending on which group a given stakeholder falls into, determines how much effort I put into getting their input. For those in the 'agree' group I plan ahead to ensure I can get time with them 'in person' to discuss and debate the proposal in real time. For those in 'accept' I email/post the document and ask for comments/feedback by a specific, reasonable, deadline. If they're too busy to respond then they've forfeited any right to criticize, complain or block the proposal later on. If they provide feedback that I don't implement then I need to have good reasons why I'm not and share that with them. The 'understand' group tends to be upper mgmt who trust me and, so long as I've gotten everyone in the 'agree' group onboard, will support the decision/proposal. This is typically done in a regular 'check in' or via email.

leetrout 6y ago

RFCs are used to great success (IMO) at HashiCorp. See more info at: https://www.hashicorp.com/blog/redesigning-hashicorp-consul-ui https://www.hashicorp.com/blog/redesigning-hashicorp-consul-... https://www.hashicorp.com/resources/closing-keynote-research-as-code https://www.hashicorp.com/resources/closing-keynote-research... Now my personal opinions on the subject: Working at HC it’s really insightful to have the RFCs to review and understand where things came from. At the same time, in my very limited experience there, they were used for gate keeping both on the authoring side and on the review side. Certainly some level of gate keeping is necessary and intended but I hold the opinion today that RFCs could / should be used everywhere and that extra work should be put in to ensure contributions and reviews are fair and welcome. On at least one occasion an RFC had a VP or higher say “no thanks” and then in out-of-band conversations it gets approved. I think I was just too naive and thought decisions and discussions would be very open. Also a couple teams worked without creating RFCs and I don’t think that was healthy, either. That’s the legalistic side of me coming out... if there’s a process for some but not all what are the exemptions and why? Managers would tap some people to write RFCs and would dissuade others. Again, probably to be expected in a large, political org and just something to be aware of if you implement RFCs at your org.

exceptione 6y ago

> Getting sign off from peers can be tricky when everyone is > busy The article mentions that you as the rfc creator ultimately takes the decision how to go forward, and should not seek consensus. from the post: > The process seeks a consent-based environment, not a > consensus-based one. If some people care about a topic a > lot and come up with a written document that explains many > things in detail, everyone can (and should) trust them. > The authors shouldn't wait for everyone's confirmation of > their proposal. When they get enough feedback, they should > be able to continue further with or abandon the idea. It's > their decision. Since they prepared the doc and collected > many comments on it, they can have a better judgment.

gingerlime 6y ago

We use a similar process, inspired by Basecamp[0]. For us it seems like the biggest challenge is getting feedback from the right people. Mostly due to the sheer number of pitches (RFCs, project proposals). And we're a small team. Also it's a bit difficult to decide what goes first and how to make sure we don't bite more than we can chew. Overall I agree with the article that the biggest benefit is from writing things and thinking about them in a structured way. Some ideas sound great, but once you start digging, problems emerge. Being able to pull the brakes even before starting, or refining the idea to a much smaller core is perhaps the most valuable and non-intuitive benefit. [0] https://basecamp.com/shapeup https://basecamp.com/shapeup

lazyant 6y ago

You don't get sign off (approval) from peers but comments from them. It's important the RFC is public and anyone can comment on it. If after a period of time there are no objections expressed in the doc (people are busy etc) then that means the objections were not that important and we can move forward.