Tips for Reducing Friction in Processes

Critique this (real) team's experiment. Good? Bad? Caveats? Gotchas? Contexts where it will not work? Read on: Overview The team has observed that devs often encounter friction during their work—tooling, debt, environment, etc. These issues (while manageable) tend to slow down progress and are often recurring. Historically, recording, prioritizing, and getting approval to address these areas of friction involves too much overhead, which 1) makes the team less productive, and 2) results in the issues remaining unresolved. For various reasons, team members don't currently feel empowered to address these issues as part of their normal work. Purpose Empower devs to address friction points as they encounter them, w/o needing to get permission, provided the issue can be resolved in 3d or less. Hypothesis: by immediately tackling these problems, the team will improve overall productivity and make work more enjoyable. Reinforce the practice of addressing friction as part of the developers' workflow, helping to build muscle memory and normalize "fix as you go." Key Guidelines 1. When a dev encounters friction, assess whether the issue is likely to recur and affect others. If they believe it can be resolved in 3d or less, they create a "friction workdown" ticket in Jira (use the right tags). No permission needed. 2. Put current work in "paused" status, mark new ticket as "in progress," and notify the team via #friction Slack channel with a link to the ticket. 3. If the dev finds that the issue will take longer than 3d to resolve, they stop, document what they’ve learned, and pause the ticket. This allows the team to revisit the issue later and consider more comprehensive solutions. This is OK! 4. After every 10 friction workdown tickets are completed, the team holds a review session to discuss the decisions made and the impact of the work. Promote transparency and alignment on the value of the issues addressed. 5. Expires after 3mos. If the team sees evidence of improved efficiency and productivity, they may choose to continue; otherwise, it will be discontinued (default to discontinue, to avoid Zombie Process). 6. IMPORTANT: The team will not be asked to cut corners elsewhere (or work harder) to make arbitrary deadlines due to this work. This is considered real work. Expected Outcomes Reduce overhead associated with addressing recurring friction points, empowering developers to act when issues are most salient (and they are motivated). Impact will be measured through existing DX survey, lead time, and cycle time metrics, etc. Signs of Concern (Monitor for these and dampen) 1. Consistently underestimating the time required to address friction issues, leading to frequent pauses and unfinished work. 2. Feedback indicating that the friction points being addressed are not significantly benefiting the team as a whole. Limitations Not intended to impact more complex, systemic issues or challenges that extend beyond the team's scope of influence.

Yet another reason estimates are ridiculous. One of the silliest things about time estimates is that the vast majority of time it takes for a team to finish something is spent waiting. For the average development team to create something of value, only 10-20% of the total start-to-finish completion time is spent actively working on the item. The majority of the time is spent waiting. 🔵 Waiting for Reviews 🔵 Waiting for team member hand-offs 🔵 Waiting on other teams or departments So much time is spent waiting… instead of asking, “How much time will it take WORKING to complete this?” You’d be better off asking, “How much time will it take WAITING to complete this?” This, of course, is impossible to answer since most teams have zero control (or even awareness) of waiting time. You’re far, far better off ditching time estimates entirely and focusing on reducing wait states instead. But how? 1] Use Flow Efficiency ↳ Few teams are even aware of the most critical flow metric: Flow Efficiency. ↳ Flow Efficiency tells you how much time is spent actively working on increments of value (features, assets, stories, etc.). ↳ Flow Efficiency (%) = Active Time / Total Time X 100 ↳ Any good workflow tool will calculate your Total Time (Cycle Time). 2] Determine Active Time ↳ To figure out Active Time, you need to track your wait states by adding a “Done” state to every existing stage in your workflow. ↳ For Example: Development -> Development Done -> Testing -> Testing Done -> Review -> Review Done -> Released ↳ The “Done” columns are your wait states.  ↳ Now, you can effectively determine Active Time for each item in your flow vs. Wait Time. 3] Improve Flow Efficiency ↳ Once you can visualize and track wait times, you can focus on fixing the worst offenders. ↳ Add team members, reduce work in progress, remove dependencies… there are many ways to minimize wait states. ↳ Any reduction made to any of your wait states will improve Flow Efficiency An average team will have a Flow Efficiency of 20%. Your team should achieve a Flow Efficiency of 40% or greater to be considered high-performing. Will this take some effort? Of course! But far less effort and total team time (and annoyance) than asking for estimates. Plus, the increase in productivity will far outweigh any loss in imagined predictability.

What if your leadership is your team’s biggest obstacle? The best leaders clear paths—they don’t block them. Ever felt your team’s productivity stalls for no reason? Here, you’ll learn how to reduce friction in your teams and organization using the 𝗙𝗿𝗶𝗰𝘁𝗶𝗼𝗻 𝗙𝗶𝘅 𝗙𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸—a simple way to transform chaos into clarity. After decades of consulting leaders and teams, I’ve learned that nobody 𝘪𝘯𝘵𝘦𝘯𝘵𝘪𝘰𝘯𝘢𝘭𝘭𝘺 creates friction, but they do. It starts small—like when I proudly rolled out a new “innovative” approval process. The result? My team spent hours navigating it instead of working efficiently. My good intentions created bad friction. Sound familiar? Here is the 𝗙𝗿𝗶𝗰𝘁𝗶𝗼𝗻 𝗙𝗶𝘅 𝗙𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸 (adapted from 𝘛𝘩𝘦 𝘍𝘳𝘪𝘤𝘵𝘪𝘰𝘯 𝘗𝘳𝘰𝘫𝘦𝘤𝘵 by Sutton & Rao): 1️⃣ Reframing: changing perspectives 📌 Purpose: Reduce friction by shifting perspectives. 🛠️ Actions: Reframe challenges as opportunities for growth or innovation. 💡 Example: A team facing budget cuts turned limitations into a chance to develop creative, cost-effective solutions. 2️⃣ Navigating: finding paths through obstacles 📌 Purpose: Help teams overcome barriers. 🛠️ Actions: Train employees to identify bottlenecks and develop workarounds. 💡 Example: During COVID-19, organizations embraced digital tools to navigate remote work challenges. 3️⃣ Shielding: protecting teams 📌 Purpose: Prevent unnecessary burdens from overwhelming employees. 🛠️ Actions: Leaders buffer teams from excessive meetings, bureaucracy, or toxic behaviors. 💡 Example: Pixar fosters creativity by shielding its teams from corporate red tape. 4️⃣ "Neighborhood" design & repair: local improvements 📌 Purpose: Optimize team environments for collaboration and efficiency. 🛠️ Actions: Simplify workflows, enhance communication, and foster supportive cultures. 💡 Example: A hospital redesigned its ER workflow, drastically cutting waiting times. 5️⃣ "System" design & repair: long-term improvements 📌 Purpose: Reimagine organizational structures for lasting impact. 🛠️ Actions: Implement large-scale changes, like rethinking hierarchies or systems. 💡 Example: Spotify’s squad model enabled faster decision-making and adaptability. Not all friction is bad. Take Amazon’s memo system: teams must write detailed narratives instead of slides. Why? It forces deeper thinking and clarity, ensuring better decisions before action. ✅ Good friction: Sparks debate, critical thinking, and better outcomes. ❌ Bad friction: Drains morale, slows progress and hinders productivity. What’s the most ridiculous process you’ve ever created or endured? Share below—we’ll laugh and learn together!

Last week, I cut a team’s delivery time from 14 days to 3. No new tools. No new hires. Most “best practices” are just busywork. I proved it in under a week. This was inside a global consumer brand. The kind where 6 departments want signoff before anything moves. The team thought every step was necessary. But most were just legacy habits. They were clinging to steps they couldn’t even explain. ___________________________________________ So I mapped out the process with them: - We looked at every step, one by one. - I asked: “Why do we do this?” - No clear answer? We cut it. What I found was that most of the 14 days weren’t spent prepping assets. They were spent waiting on feedback, file uploads, people to open emails and approvals from multiple departments. Once we stripped the unnecessary steps, here’s what the new flow looked like: One portal. One timeline. Inline comments. Instant download. Done. ___________________________________________ We removed 7 steps. Seven. Gone. Just by fixing the flow. Now the work, flows. The team moves faster. And no one’s gasping for air by Thursday If your workflow feels heavy and slow, try this: → List your steps. → Ask: “Does this actually move us forward?” → If not, cut it. You don’t need more time. You need fewer steps. Keep it lean Was this helpful? ___________________________________________ PS: I share the juicy stuff in my comment section

“Just make the team work faster.” Really? In a world obsessed with fast delivery, it’s easy to overlook the value of robust systems. If we think about it that line alone could fund our next vacation😁 ... ...but let’s be honest: 👉🏽 Most speed demands in product and project environments ignore the very systems that slow teams down in the first place. Here’s the truth: As a PM you’re not managing a clock. You’re managing a system. Yes, speed is seductive. But real velocity comes from clarity and not chaos. High-performing teams don’t burn out to move faster. They remove friction with: → Clear priorities → Streamlined approvals → Automated testing → Protected focus time This is what leads to fewer blockers, better flow, and sustainable delivery. So how do we approach the “impossible” pressure to move faster? We shift from panic to process. I use this S.Y.S.T.E.M. to reframe: S – Surface the Real Constraints Don’t absorb vague demands. Clarify goals, timelines, and what success actually looks like. Y – Yield Quick Wins Build trust by removing friction fast. Cancel one low-value meeting. Automate one manual task. S – Shine Light on Hidden Costs Use data: delays, rework, handoffs. Visibility changes the narrative. T – Translate Tech Debt into Business Language Speak in cost, risk, opportunity — not just in code. E – Establish Better Metrics than “Speed” Track predictability, quality, customer impact. Speed without value is just chaos. M – Make Bottlenecks Visible Use dashboards, reports, burn charts. Advocate with visuals, not blame. And when leadership says “go faster,” try saying: “We can push harder for short-term gains… or fix the systems for long-term velocity. Which outcome are we aiming for?” That’s leadership and not resistance. Remember you are not a magician. You are a systems thinker. You’re not there to do more with less indefinitely. You’re there to make better delivery possible for the business/organisation and the team. And if your environment isn’t built for that? Then maybe the problem… isn’t you. What’s the most unrealistic speed demand you’ve faced m and how did you handle it? Let’s hear your story Follow 👉 Benjamina Mbah Acha for insights that help you plan, execute, and deliver projects with confidence.

You built a MM team. But you’re still running an ENT process. Custom contracts. Multi-step legal reviews. Three-person approval chains for $15K ACV deals. Your reps aren’t inefficient. They’re being handcuffed. When you build a team to go down market but never adapt your motion, all you do is run ENT plays with much smaller payoffs. It’s a process mismatch, and it’s killing your velocity. Here’s what it looks like in the wild: - Your CPQ tool requires six steps for a one page contract. - Legal won’t touch anything under 3 weeks, even on redline-free deals. - Your stage definitions assume a stakeholder map, exec sponsor, and business case…for $18K. 🕺 Your reps spend more time navigating approvals than actually selling This isn’t a rep problem. It’s sales process debt. And it compounds every time you scale the team without scaling down the friction. Here are a few ideas re how to fix it: 1. Define the breakpoints across deal segments. - Don’t just build a “MM lane," but get crisp on what separates a $15K deal from a $150K one. - Identify where the process must diverge (approval logic, contracting, negotiation policy, stage definitions). 2. Build a segmented deal desk model. - Standard pricing, templatized contracts, pre-approved concessions. - Route anything under a certain threshold through a fast lane. No review, no delay. - Create process SLAs by segment. MM reps shouldn’t wait behind a $400K renewal. 3. Align stage definitions to intent and complexity, not company size. - ENT stages often assume multi-threading and exec validation. That doesn’t map to a fast moving $12K deal. - Define what “qualified” actually means in a MM motion - and cut the fat. 4. Rewire legal and finance collaboration with sales velocity in mind. - MM motions need pre-negotiated fallback positions, not weeklong redlines. - If your strategy changed but your approval paths didn’t, that’s on leadership...not legal. 5. Rethink comp plans and KPIs. - For MM, consider velocity-weighted compensation: short-cycle, multi-opportunity plays > single mega-deals. - Incentivize throughput, not just ACV. Especially when land-and-expand is the goal. 6. Pressure test your tech stack. - If your reps need a CPQ user manual for every quote, the tool’s wrong...or the process is. - Build automation around repeatable motion. Save human review for high risk or high variance deals. Scale isn’t just about more headcount. It’s about process-market fit. You don’t fix a MM motion with ENT muscle memory. You fix it by designing a system that matches the job.

If I were starting a new role as a Process Engineer, here's exactly what I’d do to understand the flow: 🔍 1. Walk the process — and don’t rush. I’d spend hours just watching. No stopwatch. No clipboard. Just observe. Patterns reveal themselves when you’re patient. 👂 2. Talk to the operators — and really listen. I'd ask: “What’s the most annoying part of your day?” “What slows you down?” “What do you wish was different?” And then I’d shut up and listen. ❓ 3. Ask tons of questions. Even the obvious ones. Especially the obvious ones. “Why do we do it this way?” “What happens if we skip this step?” Curiosity uncovers the real process—not the one on the SOP. 📷 4. Sketch the flow. No fancy software. Just a pen and paper. I'd map what I see, not what’s supposed to happen. Because often, those two aren’t the same. 🧩 5. Connect the dots — from raw material to finished product. I’d try to understand: Where are the delays? Where’s the rework? Where are people waiting on machines — or worse, machines waiting on people? Why bother doing all this? 📌 Because if I jump to solutions too fast, I’ll miss the root cause. 📌 If I rely on reports, I’ll miss the reality. And if I don’t listen to the people in it every day, I’ll never earn their trust. Understanding the flow takes time. But that’s how you find the friction. And friction is where real improvement begins. ✨ DM me if you’re stuck in a messy flow and want a second pair of eyes. Let’s find the friction — and fix it. #ProcessEngineering #ContinuousImprovement #processflowoptimization

What did you do yesterday that felt like a waste of time? Not "important but boring." Specifically: *"This should be faster."* Examples from my friction audit: → Writing follow-up emails after calls → Reformatting reports for different audiences → Turning messy notes into clear action items → Creating slide outlines from brainstorm sessions 𝗣𝗶𝗰𝗸 𝘁𝗵𝗲 𝗼𝗻𝗲 𝘁𝗵𝗮𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝘀 𝗺𝗼𝘀𝘁 𝗼𝗳𝘁𝗲𝗻. That's your AI entry point. The 5-Minute Implementation Don't research tools. Just test. Open any AI tool and say: "𝘐 𝘯𝘦𝘦𝘥 𝘩𝘦𝘭𝘱 𝘸𝘪𝘵𝘩 [𝘧𝘳𝘪𝘤𝘵𝘪𝘰𝘯 𝘱𝘰𝘪𝘯𝘵]. 𝘏𝘦𝘳𝘦'𝘴 𝘸𝘩𝘢𝘵 𝘐 𝘶𝘴𝘶𝘢𝘭𝘭𝘺 𝘥𝘰: [𝘥𝘦𝘴𝘤𝘳𝘪𝘣𝘦 𝘱𝘳𝘰𝘤𝘦𝘴𝘴]. 𝘏𝘦𝘳𝘦'𝘴 𝘮𝘺 𝘳𝘢𝘸 𝘮𝘢𝘵𝘦𝘳𝘪𝘢𝘭: [𝘱𝘢𝘴𝘵𝘦 𝘢𝘤𝘵𝘶𝘢𝘭 𝘸𝘰𝘳𝘬]. 𝘔𝘢𝘬𝘦 𝘵𝘩𝘪𝘴 𝘧𝘢𝘴𝘵𝘦𝘳." 𝗚𝗶𝘃𝗲 𝗶𝘁 𝗿𝗲𝗮𝗹 𝘄𝗼𝗿𝗸, 𝗻𝗼𝘁 𝗵𝘆𝗽𝗼𝘁𝗵𝗲𝘁𝗶𝗰𝗮𝗹𝘀. If it saves you 10+ minutes on the first try, you've found a keeper. The Bottom Line Stop asking "𝘞𝘩𝘢𝘵 𝘤𝘢𝘯 𝘈𝘐 𝘥𝘰?" Start asking 𝘞𝘩𝘢𝘵'𝘴 𝘴𝘭𝘰𝘸𝘪𝘯𝘨 𝘮𝘦 𝘥𝘰𝘸𝘯?" 𝗔𝗜 𝗮𝗱𝗼𝗽𝘁𝗶𝗼𝗻 𝗱𝗼𝗲𝘀𝗻'𝘁 𝘀𝘁𝗮𝗿𝘁 𝘄𝗶𝘁𝗵 𝗮𝗺𝗯𝗶𝘁𝗶𝗼𝗻. 𝗜𝘁 𝘀𝘁𝗮𝗿𝘁𝘀 𝘄𝗶𝘁𝗵 𝗮𝗻𝗻𝗼𝘆𝗮𝗻𝗰𝗲. Your friction points are your roadmap. 𝗧𝗵𝗶𝘀 𝘄𝗲𝗲𝗸: 1. Run your 3-minute friction finder 2. Pick your biggest time-waster 3. Test one AI solution 4. Keep what works Ready to eliminate friction systematically? → 𝗦𝘂𝗯𝘀𝗰𝗿𝗶𝗯𝗲 to *The AI Edge for Leaders*  → 𝗙𝗼𝗹𝗹𝗼𝘄 𝗺𝗲 for daily AI insights → 𝗗𝗠 𝗺𝗲 if your team needs help identifying friction points

This is a follow-on to my post last week about reducing friction to reduce the chaos that results from it. One of the most common forms of friction is the quality of the work begin passed from one person or work team to another. Measuring quality every step of the way in a process is vital for seeing the truth about how processes and work systems have been designed—and where to focus one's efforts to reduce friction. %C&A is the metric we call "the little beast." It stands for "Percent Complete & Accurate." Many of you already know about this metric since I frequently reference it in all of my books, and in many posts, keynotes, and @TKMG-Academy courses. The metric is obtained by asking downstream recipients of work, whether electronic/informational or physical products, what percentage of time they can complete whatever they're supposed to do without engaging in any form of rework. The three forms of rework are: 🔸Correcting information or physical product due to error/mistake/defect 🔸Adding missing information that should/could have been supplied. 🔸Clarifying information that should/could have been clearer to begin with. Example: If someone reports that they engage in any of these three forms of rework in approximately 3 out of 10 instances of receiving work (or 30 out of 100, etc), the %C&A for the upstream process is 70%. But . . . here's where the "little beast" raises its head. VERY often, people report VERY low %C&As . . . As in 10% quality received—or 0%, meaning 100% rework! Poor quality can be coming from external customers or internal teams as you can see in the image below. The people in Step 13 said the customer never provides 100% quality and those in Step 14 (not shown) said that they have to rework 8 out of 10 "work items" (information, in this case) received from Step 13. When cross-functional teams incorporate this metric into mapping processes or value streams (it applies to both levels of scrutiny), it's game-changing. First, most people delivering work have no idea that what they're delivering doesn't meet the criteria established by the recipients of the work. Because they've never had the conversation. Second, we find the most interpersonal or interdepartmental tension isn't due to the people involved. It's typically VERY closely tied to this metric and the frustration that results from repeatedly having to do non-value-adding work that people believe were someone else's responsibility. So, while this metric is the "little beast," it's also the most healing aspect of the work we do. Eliminating low %C&A creates significantly better working relationships, reduces stress, speeds delivery, and costs less. Give it a whirl. I'm happy to answer your questions. For those of you who have incorporated this metrics into your work, please share your stories of how it's helped solve business problems and perceived people problems that are merely work design problems. I'll add my comment below.