%% tags:: #writing/2023 #on/DecisionMaking started_date:: [[2023-04-10]] published:: project:: up:: ##### Research and idea capturing: - %% ###### [[Positive Experiments MOC]] | Updated [[2023-04-10]] # Who has the D? Decision Making model for experimentation teams ![[B5FE25ED-E549-42A0-8FD7-847D1C4F8409_1_105_c.jpeg]] **Decisions are the coin of the realm in business.** Every success, mishap, every opportunity seized or missed stems from a decision someone made — or failed to make. Yet, in many firms, decision routinely stall inside the org, hurting the entire company's performance. The culprit? **Ambiguity over who's accountable for which decisions.** 🎯 These are opening lines from Who Has the D? How clear decision roles enhance organizational performance by Paul Rogers and Marcia Blenko, first published at HBR. <iframe width="560" height="315" src="https://www.youtube.com/shorts/H2u5_-Z7kak" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe> ### Think RAPID: How to clarify decision accountability? Assign clear roles for decisions that most affect performance. 1. Who should recommend a course of action on a key decision? 2. Who must agree to a recommendation before it moves forward? 3. Who will perform the actions needed to implement the decision? 4. Whose input is needed to determine the proposal's feasibility? 5. Who decides — brings the decision to closure and commits the org to implementation? **The key is to get clear who has input, who gets to decide, and who gets it done.** ![[73D39C70-F3A0-469D-B852-600E30B302FC_1_102_a.jpeg]] ### Where experimentation decisions stall > Decision-making process can stall, usually at one of four bottlenecks: > 1. Global vs. local > 2. Center vs. business unit > 3. Function vs. function > 4. Inside vs. outside partners From my experience, two and three are the most common friction points to get experiments moving. #### Center vs. business unit Business units are in the front line, close to the customer, whereas, the center sees the big picture, sets broad goals, and keeps the organization focused on winning. Where should the decision-making power lie? #### Function vs. function Cross function decisions too often result in ineffective compromise solutions, which frequently need to be revisited because the right people were not involved at the outset. Decisions that cut across functions are some of the most important a company faces. Indeed, cross-functional collaboration has become an axiom of business, essential for arriving at the best answers for the company and its customers. ![[0903EE1D-D6DD-4AB3-974A-E830FA23D854_1_102_a.jpeg]] ## RAPID model for experiments I revisited this material after a conversion program "Start/Stop/Continue" retrospective where one of the "start doing" themes was to clarify roles and responsibilities. Now, every test card has a clear Decider, usually the experimentation ambassador leading the experiment. This person becomes the responsible for moving an idea from abstract to test in production, that means writing hypothesis, getting tech specifications, and clearing bottlenecks with support of the other roles. In a cross-function team, product, design, engineering, copywriters, UX provide input. As the orchestrator, I recommend action based on data, that means refining the testing hypothesis and supporting analysis to avoid the Decider to grade their own homework. Legal and Sr. Leadership, with veto-power, must agree — the rule of thumb is to avoid testing what we're afraid to push to production in case of a winner experiment. Developers perform, bringing concept to front-end. ![[Image 2023-04-17 at 8.47.23 PM.jpg]] ### Decision-role pitfalls In assigning roles, watch for these three: 1. Ensure that only one person "has the D." If two or more people think they're in charge of a particular decision, a tug-of-war results. 2. Watch for a proliferation of "A's." Too many people with veto power can paralize recommenders. If many people must agree, you probably haven't pushed enough decisions down far enough in the org. This system is designed to reduce micro-management. 3. Avoid assigning too many "I's" when many people give input, at least some of them aren't making meaningful contributions. Consider setting a budget for feedback rounds to empower product designers. ### Ambiguity is the enemy. For important initiatives, clarify who has the D. # Quote >If you can't make the right decisions quickly and effectively, and execute those decisions consistently, your business will lose ground. --- # Related to [[Decision-making MOC]] %% # LinkedIn post **Decisions are the coin of the realm in business.** Yet, decisions routinely stall inside the org, hurting performance. The culprit? **Ambiguity over who's accountable for which decisions.** 🎯 Opening lines from Who Has the D? How clear decision roles enhance organizational performance by Paul Rogers and Marcia Blenko, first published at HBR. I revisited this material after a conversion program "Start/Stop/Continue" retrospective where one of the "start doing" themes was to clarify roles and responsibilities. RAPID became my new mental model to assign clear roles for product-development decisions led by experiments. 1. Who should Recommend a course of action on a key decision? 2. Who must Agree to a recommendation before it moves forward? 3. Who will Perform the actions needed to implement the decision? 4. Whose Input is needed to determine the proposal's feasibility? 5. Who Decides — brings the decision to closure and commits the org to implementation? Every experiment card has a clear Decider, usually the ambassador leading the experiment. In a cross-function team, product, design, engineering, copywriters, UX provide input. As the orchestrator, I recommend action based on data. Legal and Sr. Leadership, with veto-power, must agree. Developers perform and bring concepts to life. Ambiguity is the enemy. For important initiatives, clarify who has the D. Access to details of RAPID model for decision-making in my knowledge-base. Link below.