Sending out a "Request for Comment" when establishing a new guideline

Question

Do you send out a "request for comment" when establishing a new company guideline or standard?

Companies need to establish consistent guidelines on things like development process, version control, release procedures, etc. Is it worth the effort to solicit feedback prior to publishing the final guidelines? What do you need to watch out for?

In certain cases, such as when you have experienced engineers who can draft the guidelines, or where guidelines can be revised over time, I think the answer could be "No".

Benefits

• Resolve corner cases or ambiguities prior to publication
• Better acceptance/adoption because the people that will use the guidelines were involved

Drawbacks

• Takes time
• May not get useful feedback

Answer 1

Yes, I think you're headed in the right direction in a Dale Carnegie sort of way. If you really want to get something accomplished (unit testing, coding standards, etc) often the best approach is to let them craft your ideas themselves. If you have done the research and reached a reasonable conclusion it is likely that your colleagues will reach the same conclusion if given a little guidance.

Let the other person feel that the idea is his or hers.

In general, people have more faith in ideas that they discover themselves than those that are handed to them on a silver platter.

No one likes to be sold something or told to do a thing. We much prefer to feel that we are buying of our own accord or acting on our own ideas. We like to be consulted about our wishes, our wants, our thoughts.

Ask others what or where they feel the problem is. Discuss each point and ask them their opinions on which is the best way to proceed. A few, low-key suggestions, given at the proper intervals, will influence them. Let them develop your plan or ideas themselves.

Ask questions in a friendly way, showing a cooperative spirit, noting areas where the other person is right. This will warm them up and melt any tension between you. Add in a carefully put remark here or there to give birth in the other person of a new opinion or idea. Be careful not to let them think that you are making an issue of something.

Lao-tse, a Chinese sage twenty-five centuries ago said: "The reason why rivers and seas receive the homage of a hundred mountain streams is that they keep below them. Thus they are able to reign over all the mountain streams. So the sage, wishing to be above men, puts himself below them; wishing to before them, he puts himself behind them. Thus, though his place is above men, they do not feel his weight; though his place is before them, they do not count it an injury.

-Dale Carnegie

Answer 2

Before you publish the request for comment, consider at least these few points so you have a strategy for handling the issues as they come back to you:

1. Resolution strategy. How will you handle objections, even if framed as 'minor concerns'? Will certain kinds of objections be handled differently (grammar, tone, style, or structure of the guide, compared with subject at hand)? How will you handle contention; or competing, divergent concerns?

2. Timeframes of both hard and flexible for response and action. Don't let yourself and your process get stuck in limbo waiting on affirmative congruence from everyone. The period for comment and resolution should be more or less fixed or debate will be endless. Resolving individual, specific issues, should respect some fixed timeframe, but probably won't always be reconcilable within a normal window.

3. Adoption, Amendment, and Transition. Do you have acceptance criteria for the guideline? What will the process of adoption look like, both initially, and down the road when the standard is changed? How can the standard be changed?

4. Adherance and enforcement. What are the consequences of not following the guideline? Will the process recognize a waiver, either in part or in whole from the guideline?

While it may seem, and actually be overkill for some guides, for those with broader impact, it may be useful to setup an issue tracker and treat the guideline as a project or subproject unto itself.