A critique of the Open Decision Framework, plus suggestions

[ruhbehka]

This was submitted to me via email by @dmison and I thought it raised some fair points.

• Reposting here with permission, in case others want to tackle any of it and do a pull request.

The Open Decision Framework is a great idea and I believe it is really important for teams all across Red Hat to be able to integrate the behaviours that the ODF encapsulates. However I think the current state of the ODF presents a number of barriers for adoption for smaller teams with limited resources and experience.

Disclaimer:
These are largely my personal impressions after having reviewed the framework, participated in team discussion on the topic, done the ODF training, and reviewed the ODF Study Guide. I’m not necessarily saying that the ODF doesn’t address any of the specific points I raise, but rather that I think they are important and that they might get lost in layers of other things.

It is always easy to critique something after the fact, to see the gaps when others have already done the hard work of bringing all the pieces together. I don’t want to belittle the efforts of those on the ODF initiative but rather to provide more input to refine the ODF and hone it to a sharper edge.

So what is wrong with the ODF exactly?

It’s vague

The ODF feels more like a collection of suggestions, or best practices, rather than concrete steps to take, and it describes the desired outcomes very broadly. It doesn’t speak in specifics, and it doesn’t tie outcomes directly to specific actions.

This vagueness means it’s a lot of work to get started

The vagueness of the ODF can lead to the situation where someone wants to use the ODF, reads the material, does the training, and is still left wondering exactly what to do next.

The ODF is a set of principles and practices that you need to learn, internalise, and then implement. For teams with limited resources this is a major barrier. Especially teams without communications expertise (like engineering teams) for whom communications can feel like “not my job” or too much work for no tangible outcome.

Additionally it seems that the amount of ODF material is increasing over time, making it harder rather than easier to feel that you understand it. If uncertainty about the ODF only leads you to even more material that needs to be reviewed, then that is a problem.

There isn’t a clear path for people to actually change their behaviour

As our team discovered with the Engineering Content Governor initiative, when you try to equip people with the conceptual knowledge of how to make these decisions for themselves you are simply burdening them with more work outside of their expertise. And they rarely have the time nor the motivation to become experts in another field which is orthogonal to their actual work.

This often results in not only to lack of adoption but also ineffective or counterproductive implementations.

People need to be presented with a clear path which shows them how to proceed. They need to be sure they are doing the right things and be aware of the shortcomings in their existing behaviours.

I don’t think anyone at Red Hat doubts the core values of Freedom, Accountability, Courage, and Commitment. In that regard the ODF feels like it is preaching to the choir. What we do lack at Red Hat is a clear set of steps as to how to live those values consistently in our work while still accomplishing our work goals AND being able to go home at a reasonable hour.

So how can we fix this?

I think the key elements of the ODF aren’t about decision making at all as much as they are about communication. Specifically about enabling two-way communications between decision-makers and those affected by those decisions. Almost everything in the ODF is about making sure everyone involved understands the problem, requirements, constraints, and how different choices will affect everyone involved. Everything else follows from that.

However the terms "communicate" or "communication" do not even appear in the ODF until halfway through. The ODF recommends to “state the obvious”, although it might have failed to do so in this case. :-)

1. Fix the format

A slide-deck is great to have, but it needs to be a summary of the core concepts. It needs to be in support of a single document that provides the full content of the ODF. The training shouldn’t be additional material, but rather just the audio-visual presentation of the materials for those who learn better that way. People shouldn’t have to read the document and watch the training to fully understand all the material.

2. Reduce the number of abstract concepts

Talk less about abstract values like (openness, participation, community, etc) and more about common underlying concepts like two-way communications & expectations management that make it work. These need to be tied to clear process steps.

3. Make it pick up and go

Provide immediately actionable steps for the different stages (checklists, fill-in and go document templates, etc) and split up the “common fact-base” into a series of more specific documents, mapping them to different project phases. Define key phase points (initiate, first contact, reviews, final, pre-mortem) and what to do at each.

4. Emphasis the immediate benefits

Emphasise the immediate tangible benefits of the process at each stage, rather than the long term benefits (ie what’s in it for me right now?) Don’t oversell concepts like “community building” which might make great sound-bites but in reality mean even more work.

5. Make the materials modular

Providing actionable steps & resources, objectives and defined benefits for specific phases, you make it easy for people to adopt the parts they need, want, or have the resources for. This can make it much easier for people to adopt the ODF quickly with minimal investment and start seeing the benefits. It also makes it easy for them to tweak the parts that don’t work well or fit with them.

A modular approach could also make it easier for people to contribute to and improve the ODF processes.

6. Discuss Anti-Patterns.

The ODF does make mention of undesirable behaviours in the “what the ODF is not” section and some of the “pitfalls” sections in the training. But it doesn’t specifically address behaviours which might seem okay but in fact are not (like sending massive 5 page emails or the “big reveal” approach to announcements). I feel these should be collected in one place that covers this as well as referring to them where they apply in other sections.

Bonus Points:

Web-based tools that support the processes and concepts of the ODF. The ODF shouldn’t be tied to such tooling but they should exist to make it as easy as possible for those who wish to use them.

Wrapping up

The ODF tries to encompass the behaviours of openness and community participation, which should be the way we are already behaving at Red Hat. I’m not exactly sure what ODF 2.0 would look like or how to get there, but maybe it’s time to move beyond talking about the abstract and get onto giving people concrete steps to action instead.

I think that with some adjustment the ODF can become the basis of long term behavioural and culture change in Red Hat. However to do that, it needs to be much easier and accessible to provide immediate benefit to people with minimal outlay in effort.

Don’t try to force cultural change, make it easy to do the right thing and let it sneak up on them.

[semioticrobotic]

May we all receive feedback this generous, kind, forthright, and helpful in everything we do.

[Nebhatia]

Very insightful and well thought out -- this feedback can be applied to other leadership programs as well.

[alexismonville]

Great feedback indeed! One way to answer this need for concrete steps could be to use the template to gather facts as a guideline. Using a Google shared doc (or other online sharing system) help to drive conversation using suggestion and comment. We could guide people that want to use the ODF directly to the template, and try to make the template answer their questions as they are coming.

…

On Wed, Apr 12, 2017, 12:49 Nebhatia ***@***.***> wrote: Very insightful and well thought out -- this feedback can be applied to other leadership programs as well. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#17 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA5UeKvuSnHj7tvBiUh6Lm8nvZDisMpxks5rvQCNgaJpZM4L9r87> .

[ruhbehka]

Great suggestion @alexismonville - I went ahead and added that resource: https://github.com/red-hat-people-team/open-decision-framework/tree/master/common-fact-base-template

@dmison Let us know if you have other ideas for how to simplify putting ODF into practice! I'm going to leave this issue open for now, because I think we've only partially addressed it.