Built from a real, anonymized Gorilla Coach engagement to show what a Friction Brief looks like. The case is an illustrative amalgam, and the practitioner persona is added for illustration. No confidential data is shown.
THE GORILLA COACH
Friction Brief
Prepared for a conversation with leadership — not a document to send and wait on.
Illustrative case: This is an amalgam based on a real engagement. Names, roles, and identifying details have been changed to preserve confidentiality.
Background
The Audit
01What Surfaced
Raw observations from the interview
Leadership’s standing request is for development to go faster or for QA to be shortened. Riley describes unclear requirements and back-and-forth between groups as the larger drag.
Riley’s teams join a request at technical design. What happens at project initiation and analysis, including how many people are involved, is outside Riley’s view.
Riley could not name anyone who holds the full path from request to production. Records exist, and projects that were stopped, restarted, or rebuilt make start-to-finish dates inconsistent.
The business asks for speed and is also the hardest group to reach when a question needs an answer.
Defects turn up repeatedly, in testing and at deployment, and send work back until resources free up to fix them.
When executives declared a regulatory change critical, it was pushed through. Reviews were rushed, and people worked overtime. Riley calls it an exception.
Riley has not tried to show leadership that the delay sits somewhere other than development or QA, and said they would not know where to start.
A request takes four to six months from first ask to production, roughly 17 to 26 weeks. In Riley’s words, everybody knows it takes a few months.
A third to half of that time is spent waiting.
Four or five formal sign-offs, with a possible fifth at deployment validation that Riley is not sure about. Riley expects there are more that they do not see.
Five or six handoffs, never counted.
One request in five to one in four needs rework, roughly 20 to 30%.
Three to five new table requests arrive each month, with several active at once.
Rework is understood as going back a stage or two, from testing to development or from analysis back to the request. How far back it can travel is unknown, and no one has traced it.
The first stage, initiation and analysis, may hold a large share of the elapsed time. It sits outside Riley’s view, and no one reports on it.
02The Pattern
Leadership is fixing the stage it can see
LEVERAGE POINT 6 OF 12 — INFORMATION FLOW
(Donella Meadows, Places to Intervene in a System)
Leadership’s standing request is for development to go faster or for QA to be shorter. Those stages have owners, schedules, and someone reporting on them, so the request lands there. Nobody holds the whole path from request to production, which is why the request keeps returning. The stage being pushed is one of several, and no one can say how much of the elapsed time it holds. This is sometimes called the streetlight effect: effort goes where it is easiest to see.
The estimates in this Brief point somewhere else. If a third to half of a four-to-six-month request is spent waiting, speeding up development leaves that time untouched. The waiting sits in the gaps between groups: the business, the product group, the architects, development, testing, UAT, and the deployment window, each reporting into a different part of the organization. In Riley’s words, it takes a lot of different people, and that is probably why nothing changes.
There is also evidence the path can move. When executives declared a regulatory change critical, reviews were rushed, and the work went through. What changed was a decision with authority behind it, not the capability of the people doing the work. That suggests the constraint is how the groups connect, more than how fast any one of them works.
03Cost of Inaction
What this is costing the organization
Figures are Riley’s own estimates, not independently verified. The weeks carry the argument, not the precision of any one number.
What this adds up to: every table request spends four to six months in the path, and a third to a half of that, roughly 6 to 13 weeks, is spent with no one working on it. With three to five new requests a month, 12 to 30 requests are in the queue at any time, and one in five to one in four of them goes back for rework that no one has measured. Pushing development to go faster leaves the waiting untouched.
What we cannot see yet
How long the first stage takes, since Riley’s view starts at technical design. How far back rework can travel. How many sign-offs and handoffs there are in total. These three numbers decide whether the problem sits in development, in the first stage, or in the gaps between groups. No interview can supply them. A value stream mapping session with every group in the room can.
This Brief stops at the cost in time on purpose. Time is the cheapest cost to defend, and the next steps up, salary and revenue impact, need inputs only the business can state. A cost-of-delay figure from the business, brought into the same session, would make the case stronger than any estimate built alone.
04Recommended Actions
Where to start
Primary action: hold a value stream mapping session. Bring the business, the product group, the architects, development, testing, UAT, and deployment into one room, with someone who has standing to convene them, either an internal sponsor or an outside facilitator. Map one recent table request from first ask to production, marking each handoff, formal sign-off, wait, and rework loop, with the time against each. The session replaces estimates with measured numbers: the real lead time and waiting share, the full count of sign-offs and handoffs, how long the first stage takes, and how far back rework travels. It needs a sponsor beyond what the development manager can authorize alone, and every group in the room for the session.
Secondary action: name someone to hold the whole path. Today nobody sees a request from first ask to production, which is why the request keeps landing on development and QA. This could be one person, or a small group with a member from each stage, who reviews start-to-production dates for each request on a regular cadence. It can begin before the mapping session and gives the session real dates to start from.
Resources — Working the System
05Decision Authority
How to bring this to different stakeholders
Presenting to your development manager
You have said your development manager cannot fix this either, and that is probably accurate for a problem that crosses several groups. Lead with the time: four to six months, up to half of it is waiting, estimated from your own experience. Then add to the standing request instead of replacing it. Development is one of several stages, and nobody yet knows its share. A phrase that keeps you both at the same table is “here is an experiment we could run,” not “development is not the problem.” The ask is for your manager to carry the request to someone who can convene the other groups, since neither of you can do that alone.
Presenting to the product group
The product group signs off first and sits at the start of the path you cannot see. Open with a question, not a finding: when does a request first reach you, and what happens before it comes to us? Stay with observable steps so the conversation does not sound like a claim that the delay starts with them.
Presenting to the business
The business is the source of the request for speed and also the group that is hardest to reach when a question is waiting. That is a sensitive pairing. Leave response time out of the opening and invite them in: they hold the cost-of-delay figure you do not, and a value stream mapping session gives them a place to state it. If the conversation turns defensive, return to specific, observable events, such as one request and what waited, and stay away from judgments about how the business works.
Finding the person with standing across all the groups
You could not name one person who can bring every group together, and that is a finding in itself. Ask your development manager who they would go to with a problem that crosses groups. The answer tells you who could sponsor the value stream mapping session.
06Practitioner Actions
What you can do regardless of what leadership decides
- Start a simple log on the next three table requests. Record the date requested, the date it reached technical design, each handoff and sign-off you can see, and the date it reached production. You do not need permission to start a log. Three requests turn “a few months” into your own dates, and the next conversation starts from data you collected instead of an estimate from memory.
- Ask your architect and product counterparts one question: when did this request first reach you? It is ordinary curiosity, it needs no authority, and it begins to show you the first stage, where your own view starts at technical design.
- Ask what made the regulatory rush job fast, then list which of those moves could be repeated on ordinary requests. This is a bright spot, something that already works inside your own organization. Bring it to your development manager as an experiment to try. It lets leaders adopt a change without conceding that anything was broken, since the organization already does it.
Appendix — Where the Data Came From
If someone asks where a number in this Brief came from, this is how each figure was reached. Every input is Riley’s own estimate from the interview and was not independently verified. A month is taken as about 4.3 weeks, so four to six months is 17 to 26 weeks.
| Input | Value | Where it came from | How it is used |
|---|---|---|---|
| Lead time per request | 17 to 26 weeks | Riley’s estimate, four to six months | Starting point |
| Share of time spent waiting | A third to a half | Riley’s estimate | Idle weeks = lead time × share |
| Idle weeks per request | Roughly 6 to 13 | Calculated from the two rows above | A third of 17 weeks to half of 26 weeks |
| New requests per month | Three to five | Riley’s estimate | Requests in flight = requests per month × lead time in months |
| Requests in flight at once | Roughly 12 to 30 | Calculated from the rows above | Three requests × four months, to five requests × six months |
| Rework | One in five to one in four, about 20 to 30% | Riley’s estimate | Reported as stated, not used in a calculation |
Want to see what this looks like for your own team?
The Friction Audit is in development. Join the waiting list for early access and a launch discount code.
Join the waiting list Do a Friction Audit with me →This sample is an illustrative amalgam based on real, anonymized client work, with a practitioner persona added for illustration.