Case studies

20 case studies. Field-tested.

Real engagements from the lateralworks team across semiconductor, hardware, software, and complex-systems programs. Names and sector-identifying details have been removed (projects less than 10 years old). New cases added regularly.

PracticeAll Client Projects FTTM Coaching

© 2026 lateralworks Page 1 › › Case study Three teams, three breakthroughs How the challenge process found technical and schedule breakthroughs inside three storage development programs Case study series. The client is a major disk-drive storage company operating at extremely high volume under aggressive time-to-market pressure. This paper is published anonymously at the client’s request: individual names have been removed from the text and blurred in the artifacts, and internal program codenames are retained as they carry no external meaning. All photographs, flip charts, and schedule charts are unretouched originals from the engagement archive. Prepared by lateralworks Fast time-to-market practice Date July 2026 Engagement period 2014–2015 Online lateralworks.com Case study series -- 1 of 24 -- › Three teams, three breakthroughs › › › © 2026 lateralworks Page 2 Table of contents Three teams, three breakthroughs Abstract 03 01 — The challenge process 04 02 — Watson: a roadmap rebuilt in a week 11 03 — Rainier: the technology that was not required 16 04 — Slider Bias: learning twice as fast 19 05 — What made the breakthroughs repeatable 22 References 24 Core thesis. A schedule gap is not evidence that requirements must be relaxed. Treated correctly, the gap is raw material: the pressure that forces a team to surface its assumptions, challenge them one by one, and discover ways of working it had quietly classified as impossible. Across three programs at the same client, that discipline produced a modeled fifteen-month acceleration on one roadmap, three- and four-month pull-ins on a drive program, and a doubling of learning cycles on an advanced technology effort — without de-featuring a single product. -- 2 of 24 -- › Three teams, three breakthroughs › › › © 2026 lateralworks Page 3 Overview Abstract Late programs rarely lack effort; they lack new thinking. In 2014 a major disk-drive storage company with extremely high volume and aggressive time-to-market pressure had several of its most important development programs trending late at the same time. One roadmap-defining product family was roughly ten months behind its first major deliverable. A flagship drive program was three months late and drifting further. An advanced recording-technology effort carried a six-week gap with a progressive slipping trend and, worse, a plan that assumed its experiments would work the first time. Each team had already spent months trying to pull the schedule in. Each had concluded, reasonably, that everything that could be done was being done. This paper documents what happened when those teams were taken offsite, one day per program, and run through the lateralworks challenge process [1] — a structured application of Edward de Bono’s lateral thinking [2, 3] to engineering schedules. The process is simple to describe: make the schedule gap visible and undeniable, surface the assumptions that define the current plan, select the ones that actually control the outcome, ask why each is believed, and then generate alternatives with the constraints deliberately switched off. Ideas are harvested, treated, and driven into the schedule within seven days, while the reasoning is fresh and the team still owns it. The three workshops produced three different kinds of breakthrough. The Watson team challenged two technology-gating decisions, modeled each alternative directly in the schedule, and found a combination worth roughly fifteen months of pull-in; it then rebuilt its roadmap around the result within one week. The Rainier team discovered that a headline technology everyone treated as mandatory was desirable but not required, removed it along with the gating components it dragged in, and moved its desktop deliverable from October to July and its enterprise deliverable from December to August. The Slider Bias team, facing unknowns no schedule trick could remove, restructured its experiments to double its learning cycles inside the same window — trading a marginal three-week pull-in for a structural change in how fast it could learn, which later matured into a four-month pull-in of the learning-complete date. The paper explains the challenge process itself, then walks through each engagement: the situation before the workshop, what was done in the room, and what the team achieved afterward — with the original workshop photographs, flip charts, and schedule trend charts as evidence. It closes with the patterns the three teams shared, and the reason the method transfers: none of the breakthroughs came from added people or money, and none compromised a requirement. They came from permission to re-examine what everyone already believed. -- 3 of 24 -- › Three teams, three breakthroughs › › › 01 The method The challenge process © 2026 lateralworks Page 4 Every project plan is a stack of assumptions wearing the costume of facts. Most are invisible to the team that holds them — not because they are hidden, but because they have been true for so long that nobody remembers deciding them. The challenge process exists to drag those assumptions into daylight, test whether their reasons still hold, and use the ones that fail as openings for new ideas [1, 4]. The method descends from Edward de Bono’s lateral thinking, which lateralworks adapted for engineering programs over three decades of consulting work [2, 3]. De Bono’s challenge technique starts from a deliberately non-threatening question: not “this is wrong,” but “why is this done the way it is done — and are the reasons still valid?” The question matters because challenge is never an attack. It works best with cohesive teams who are given explicit permission to break free from the accepted way of doing something, and it fails in rooms where an idea can be shot down before it has lived for thirty seconds. Ed Catmull describes the same precondition at Pixar: people who feel unsafe suggesting ideas do not suggest them, and the organization loses exactly the ideas it needs most [5]. -- 4 of 24 -- › Three teams, three breakthroughs › › › © 2026 lateralworks Page 5 Two moves Why challenge works on schedules Applied to a late program, the challenge process makes two moves that ordinary schedule reviews never make. First, it reframes the schedule gap. A gap normally functions as an accusation — proof the team is late — and teams respond to accusations by defending estimates or negotiating requirements downward. In a challenge workshop the gap is repurposed as fuel: it creates the urgency to find solutions, and the facilitators take the two easy exits off the table. The team may not prove it is late, and it may not relax requirements to meet the date. What remains is the hard, productive question: what would have to be true for this schedule to close without compromising the goals [1, 6]? Second, it separates idea generation from idea evaluation. During the generative phase the thinking is deliberately unconstrained (green lights only, no “red-lighting” of ideas) because evaluation reflexes are precisely the machinery that keeps a team inside its current frame. Constraints re-enter later, during harvest and treatment, when each surviving idea is shaped, strengthened, and corrected against reality [2]. The sequence sounds trivial. It is the difference between a brainstorm that produces wall decorations and a workshop that produces a new baseline schedule. Figure 1. The challenge process. The generative half runs unconstrained; constraints are re-applied only after ideas exist. Obvious items are done or cut on the spot, and the cycle refreshes every two to three months. Surfacing the current thinking A workshop begins days before the room. Team members brainstorm their “current thinking” in advance: every belief that shapes the plan, written as short declarative statements on cards. The facilitation gives the statements a grammar, because vague worries cannot be challenged. Four sentence stems do most of the work: it is essential that… (what must always be included), …dominates our thinking (what ideas control us), we must avoid… (what we are steering around), and we must stay within… (the boundary conditions we accept) [1]. The taxonomy — essential factors, dominant ideas, avoidance factors, boundaries — comes -- 5 of 24 -- › Three teams, three breakthroughs › › › © 2026 lateralworks Page 6 straight from de Bono’s toolkit [2], and it forces both explicit assumptions and the more dangerous implicit ones onto paper. Assumptions are not right or wrong at this stage. The aim is only to become aware of them, because an assumption nobody has written down is an assumption nobody can challenge. Figure 2. Workshop in progress: the team nominates assumptions to challenge with colored dots. Roughly eight assumptions typically survive the vote. lateralworks engagement archive. Select, ask why, do or cut The full assumption wall usually holds forty or more statements — far too many to work. Dot voting cuts it to a short list of roughly eight. Each survivor then faces the same three questions: Why do we think this? What are the reasons? Are the reasons still valid? Some items collapse immediately into action — if it can be done now, do it; if it can be cut now, cut it — and go to a Do/Cut chart. The interesting ones are those whose reasons have quietly expired: a spec inherited from a previous product, a boundary set by a supplier constraint that no longer exists, a “must” that turns out to be a preference with seniority. Those become the openings. For each, the team brainstorms how the thing could be done differently, and the ideas are captured with their reasoning intact [1, 4]. -- 6 of 24 -- › Three teams, three breakthroughs › › › © 2026 lateralworks Page 7 Figure 3. Left: the assumption wall — every card a belief that shapes the plan. Right: the Do/Cut chart after selection; items that can be acted on immediately are done or removed on the spot. Two identifying references are blurred. Converting statements into challengeable form is itself a skill the workshop teaches. “The task has a twenty-day duration” is not challengeable; it is a fact about the current plan. “We cannot reduce the feature set to accelerate the schedule” is challengeable — it contains a hidden decision. During the workshops documented here, statements like “we are not able to reduce non-critical firmware features” and “we must deliver the full performance target in the first release” moved from the untouchable pile to the challengeable pile once the team wrote them down and looked at them in daylight [1]. From why to ideas to a seven-day plan The output of a challenge round is not a feeling of possibility; it is chart paper dense with reasons and ideas, each idea traceable to the assumption it escaped from. Ideas are harvested into three bins — specific (implementable now), a beginning (worth investigation), or a concept (a generator of further ideas) — and then treated: shaped by the real constraints, strengthened, corrected, and differentiated from the current way of working [1, 2]. The last hour of every workshop converts the surviving ideas into a seven-day action plan with named owners, because the half-life of workshop energy is short. The teams in this paper acted on every workshop decision within seven days, and every engagement scheduled a refresh: a repeat of the cycle every two to three months, because a plan accumulates new assumptions the way a hull accumulates barnacles [1]. -- 7 of 24 -- › Three teams, three breakthroughs › › › © 2026 lateralworks Page 8 Figure 4. Left: a challenged requirement — the humidity spec — worked from reasons to alternative ideas, including a spec change and field validation. Right: the seven-day plan that ends every workshop. A name and two identifying references are blurred. Two companion exercises round out the toolkit. The concept triangle abstracts a first idea into its underlying concept, then uses the concept to breed more ideas — a fast route out of the obvious. And when a team needs distance rather than depth, the facilitators reach for provocation techniques: reversal, escape, wishful thinking [2, 3]. In one exercise a recording-subsystem group started from “hit areal density with the current head and media,” extracted the concept “improve signal-to-noise,” and generated a chain of ideas running from channel optimization to waveform and coding changes — territory the original framing had walled off. -- 8 of 24 -- › Three teams, three breakthroughs › › › © 2026 lateralworks Page 9 Figure 5. Left: a concept-triangle exercise from a workshop breakout — idea to concept to more ideas, in marker. Right: a challenge exercise chart — “must wait for completion before starting evaluation” challenged with “do we have to wait?” Figure 6. A challenge pair from a group exercise: the assumptions and reasons chart (left) feeding “how we can do it differently” (right) — prioritized learning versus ship deliverables, dedicated resources, and design alternatives. -- 9 of 24 -- Challenge principle What the gap is for “Do not use the gap to prove you are late. Use it to force new thinking.” Facilitation principle, challenge workshops lateralworks program archive, 2014 © 2026 lateralworks Page 10 -- 10 of 24 -- › Three teams, three breakthroughs › › › 02 Case one Watson: a roadmap rebuilt in a week © 2026 lateralworks Page 11 Watson was the program that defined the client’s next product family, and it was in the worst shape of the three: roughly ten months late against its first major deliverable, on a schedule the team itself rated high risk. The plan stacked too many new technologies into the same first product — a new controller, a new unified firmware architecture, a new recording mode, a new drive-security feature — so every immature element gated every other one. Three months of performance-to-schedule history and repeated acceleration attempts had produced no solution. The working assumption inside the team had hardened into fatalism: the project was late, little could be done, and the technical risks meant it would probably get later [1, 10]. Figure 7. The Watson challenge workshop: schedule on the projector, challenge charts taped across the wall. lateralworks engagement archive. -- 11 of 24 -- › Three teams, three breakthroughs › › › © 2026 lateralworks Page 12 In the room Challenging the gates The workshop followed the standard arc — assumptions, dot vote, why, ideas — but what distinguished Watson was where the votes landed. The team’s short list converged on the technology-gating decisions embedded in the first product definition. Five “big hitters” came out of the challenge round: do not gate the program on the new controller silicon; decouple the new unified firmware architecture from the first release; drop the new drive-security feature from the initial release; make the first product the 3.5-inch desktop drive rather than the hardest form factor; and do not attempt the mobile variant first. Each of these had lived in the plan as a requirement. Under the question “are the reasons still valid?” each turned out to be a choice [1]. Figure 8. Watson challenge charts: release-content assumptions worked through alternatives — using the proven architecture as a base, first product on the desktop platform, replacing a phase with existing programs. What was done. Rather than debate the ideas, the team modeled them. Each acceleration idea was explored for practicality with management constraints deliberately removed, then implemented individually in the schedule to measure its real pull-in potential. Taken one at a time the results were sobering — a few days each, under two weeks in the best case. The breakthrough came from combination: challenging the new controller in the first test vehicle (use the proven alternative instead), challenging the new firmware architecture in the first release (carry the existing generation forward), and sequencing both so the new recording mode could be learned on a lower-risk platform. Combined, the ideas accelerated the recording-technology learning and produced a net modeled pull-in of roughly fifteen months [1, 10]. -- 12 of 24 -- › Three teams, three breakthroughs › › › © 2026 lateralworks Page 13 Figure 9. The combination worksheet: each challenge idea with its measured pull-in, risk notes, and cost-of-delay arithmetic, built live in the room. The cost side was quantified in the same room. The program’s business-case model put a one-month schedule change at roughly 47 million dollars of profit before tax. A ten-month acceleration was worth about 475 million dollars; the associated cost — mainly a two-percent cost-of-goods penalty from the interim design choices — modeled at about 214 million; the combined case cleared 261 million dollars in favor of moving [10]. Making the money visible mattered, because it converted an engineering argument into a business decision the executive staff could support without re-litigating the technology. -- 13 of 24 -- › Three teams, three breakthroughs › › › © 2026 lateralworks Page 14 Figure 10. The business case built during the workshop: sensitivity of profit before tax to schedule, volume, price, cost, and R&D — and the trade-off table for the ten-month pull-in scenario. What was achieved The team decided in the room to act on every workshop decision within seven days. A series of one-on-one meetings with functional stakeholders ran that week; a decision meeting the following week converged the new development strategy; and the fact that the team — not a consultant, not an executive — owned the proposal is what pulled the executive staff behind it. Within one week of the workshop the program had a re-baselined schedule on the new, faster, lower-risk approach, and the product roadmap was redrawn around it [1, 10]. Figure 11. The rebuilt roadmap: staged stepping-stone products on each track, capability added one step at a time — replacing a single first product that had stacked every new technology at once. The schedule trend charts tell the before-and-after story with no narrative needed. Before the workshop, the companion 4-terabyte product’s milestone trend had just absorbed a sixty-day slip and sat twenty-nine days late against its window. After the re-baseline the same milestone ran a flat green line — ten days early against the new commitment, week after week. Flat green lines are what a solved schedule looks like in the client’s wigglechart discipline, where each weekly dot is a prediction and the slope is the truth [6, 10]. -- 14 of 24 -- › Three teams, three breakthroughs › › › © 2026 lateralworks Page 15 Figure 12. Watson-family milestone trend, before and after: a sixty-day slip converging late (left) versus the re-baselined plan running ten days early and holding (right). lateralworks fastProject wigglecharts, client program archive. -- 15 of 24 -- › Three teams, three breakthroughs › › › 03 Case two Rainier: the technology that was not required © 2026 lateralworks Page 16 Rainier was a flagship 3.5-inch, two-platter, 7200-rpm program with a desktop deliverable due in June 2015 and an enterprise variant a month behind it. When the team walked into its challenge workshop it was approximately three months late and trending worse, for a familiar reason: the plan required a stack of new technologies — new mechanics, a new servo scheme, a new head-media interface, a dual-stage feature the whole roadmap treated as its centerpiece, a new preamp, and new firmware — and every one of them was on the critical path [1, 10]. Figure 13. The Rainier challenge workshop. Schedule scrub on the projector, challenge and assumption charts on the boards behind. -- 16 of 24 -- › Three teams, three breakthroughs › › › © 2026 lateralworks Page 17 In the room Desired is not required The workshop’s pivotal exchange was short. One of the required technologies — a head-media innovation everyone referred to as load-bearing — was put under the standard questions: why is it in the plan, and are the reasons still valid? The answer that emerged, once the capacity and performance math was worked on the wall, was that the technology was desired but not required to meet the program’s stated goals. It had entered the plan when targets were different, survived every review since, and nobody had re-examined it because challenging a headline technology feels like challenging the roadmap itself. This is the textbook dominant idea: perfectly valid once, invisible now, controlling everything [1, 2]. What was done. The team removed the technology from the program. The decision cascaded: dropping it also removed the gating items it dragged into the plan — a new suspension design and the new preamp generation — and it simplified the firmware effort that had been carrying compatibility for both configurations. Three critical-path chains disappeared in one decision [1]. The follow-through was deliberately careful, because removing a technology is the kind of workshop decision that dies in the parking lot. The core team met afterward to confirm the conclusions still held, and brought in independent experts to re-verify the assumptions. The open concern — closing capacity without the removed technology as an enabler — was answered with systems thinking rather than heroics: adopt the new generation of the data-refresh firmware, which cut the performance cost of each refresh; use that headroom to relax the adjacent-track-interference requirement from 1,500 to 750, and then to 300 with modest additional risk; and offset the residual performance loss with actuator and seek-time improvements from the servo and mechanics side [1]. One team member’s account of the week captures the mode of thinking: the removal initially threatened random-write performance under some workloads, the discussion got lively, and the servo and mechanics group volunteered compensating adjustments — in the team’s own words, “a good example by the team to identify how to help solve problems regardless of origin.” The team held to the removal despite the risks, “because that decision alone should allow us to keep the newer timeline” [1]. Churchman’s systems dictum applies exactly: systems fail when their managers decide some part of the world is outside the system and not subject to control [8]. This team widened the system until the problem fit inside it. What was achieved The desktop deliverable moved from October 2015 to July 2015. The enterprise deliverable moved from December 2015 to August 2015 — a three- and four-month pull-in respectively, on a program that had been drifting the other way. The wigglechart shows the mechanism: a red trend climbing toward January 2016, then a near-vertical drop as the challenge decisions landed, then the signature flat green line, fifty-three days early against the datacenter qualification window and holding steady week over week [10]. -- 17 of 24 -- › Three teams, three breakthroughs › › › © 2026 lateralworks Page 18 Figure 14. The Rainier trend: predicted finish for datacenter qualification shipment falling from late December to early August after the challenge decisions, then holding fifty-three days early. The program lead’s name is blurred. lateralworks fastProject wigglechart, 02-Oct-2014. The weekly working notes from the period show what the new operating rhythm looked like: what-if scenarios run and priced in days, alternatives confirmed with the recording-subsystem team, schedule updates presented at the program review with concerns raised and owned. They also show the honest cost of moving fast — the quick decision to drop the technology created a suspension-availability problem that had to be worked the following week, and strategy direction from above the team changed more than once, resetting parts of the schedule each time. The challenge process does not remove turbulence. It gives the team a way to keep converging through it [1, 9, 10]. Figure 15. Left: a week of what-if scenario work from the program’s status notes. Right: the team working the re-baselined schedule at a follow-up session. -- 18 of 24 -- › Three teams, three breakthroughs › › › 04 Case three Slider Bias: learning twice as fast © 2026 lateralworks Page 19 Slider Bias was a different animal: an innovation project rather than a product program, chartered to prove out a head-technology building block ahead of the drive programs that would consume it. Its problem was not a stack of gates but a plan shaped like a product schedule wrapped around research work. It assumed one cycle of learning — right the first time — on questions where the team openly admitted it did not yet know what it did not know. Face-to-face time between the two development sites was scarce, assumptions went unchallenged, and the end milestone carried a six-week gap with a progressive slipping trend [1, 10]. Figure 16. The Slider Bias challenge workshop, with the challenge flow chart on the screen and the working lists building on the right. -- 19 of 24 -- › Three teams, three breakthroughs › › › © 2026 lateralworks Page 20 In the room Attack the learning rate, not the date The workshop reframed the problem before it solved it. For an innovation effort, the template the team had built its plan on was wrong in one specific way: development programs mature a product, so their schedules optimize the rate of maturity — but innovation projects buy learning, so their schedules should optimize the frequency of the learn-and-fail cycle [1]. Once the team saw its plan through that lens, the challenge targets picked themselves. Why does the design-of-experiments run as one monolithic block? Why do wafer designs wait for full definition before starting? Why is there one learning cycle when the whole point is to learn? What was done. Three structural decisions came out of the room: risk-start the wafer designs for the new head feature rather than waiting; break the design-of-experiments into smaller pieces so testing could start earlier and a second learning cycle would fit inside the same window; and run more activity in parallel, accepting a known resource-contention risk. Around them came supporting moves in the same spirit: four hours of face-to-face core-team time every week for the following month, alternating between the two development sites; an external supplier added to the plan to accelerate adoption on datacenter programs; the wafer tasks broken down to expose their real dependencies; and a scrub of the component-level test schedule [1]. What was achieved Measured in calendar days the immediate pull-in was marginal — about three weeks against a milestone still trending sixty-two days late. Measured in learning it was a breakthrough: the team doubled its learning cycles inside the same time frame, which de-risked the schedule and doubled its chances of finding solutions to the unknowns that were the real threat. The energy shifted with it; the team’s own assessment afterward listed “forced us to think differently,” “focus on accelerated learning, not just the end date,” and “greater confidence in the schedule” among the changes it would keep [1]. The structural change compounded: within weeks the program carried an early completion scenario for its learning — plans in place for the required wafer designs and risk mitigations — that represented a four-month pull-in of the learning-complete date, alongside a conservative scenario holding an additional design iteration in reserve [1, 10]. -- 20 of 24 -- › Three teams, three breakthroughs › › › © 2026 lateralworks Page 21 Figure 17. The Slider Bias trend at workshop time: sixty-two days late and wiggling upward. The pull-in that followed was modest in days — the breakthrough was doubling the learning cycles inside the same window. lateralworks fastProject wigglechart, 13-Oct-2014. Figure 18. The team working the still-open questions at the end of the workshop — alignment with programs, the technology building-block process, and the physics it did not yet understand. -- 21 of 24 -- › Three teams, three breakthroughs › › › 05 Synthesis What made the breakthroughs repeatable © 2026 lateralworks Page 22 Three teams, three different breakthroughs: a roadmap rebuilt around staged learning, a headline technology removed because its reasons had expired, and an experiment plan restructured to double its learning rate. None of the three required new headcount, new budget, or a single relaxed requirement. That is the point of the method, and it is worth being precise about why it worked here, because the preconditions are reproducible [1]. Every team had the same three ingredients before the workshop. First, an accurate schedule with trend history — the wigglechart discipline of predicting the finish weekly and watching the slope — so the gap was a measured fact rather than an opinion [6, 9]. Second, leaders of a particular type: senior engineering program managers, technically respected, able to see outside their own project. Third, a team that had already tried everything inside its frame, missed its dates anyway, and knew it — teams, in other words, that were ready to be told the problem was the frame [1]. -- 22 of 24 -- › Three teams, three breakthroughs › › › © 2026 lateralworks Page 23 Patterns Why the method transfers The gap did the motivating; the process did the steering. In each room the facilitators removed the two standard escape routes — proving lateness and relaxing requirements — and the easy trade-off of de-featuring the product was explicitly taken off the table. What remained was creative pressure. People can think creatively to accelerate a schedule; doing so does not mean working harder, it means working differently against the same goals [1, 4]. The three cases put numbers on that claim: fifteen modeled months, three and four real months, and a doubled learning rate. The assumptions that mattered were never secrets. The controller gate, the mandatory technology, the monolithic experiment plan — every one sat in plain sight in the plan, defended by reasons that had once been good. That is exactly what the psychology of entrenched belief predicts: minds favor information that confirms what they already hold, and groups convert shared beliefs into identity, which is why declarations of confidence say more about the coherence of the story than its truth [11]. A structured, non-threatening “why?” is the cheapest known instrument for breaking that grip — much cheaper than the crisis that otherwise does it [2, 11]. Speed of action preserved the gains. Every team converted workshop output into a seven-day plan with owners; Watson re-baselined its entire program inside a week. The refresh cadence — a one-day challenge offsite every two to three months — kept the plans from silting back up, and matches the practice documented across the fastest teams lateralworks has studied [1, 7]. And the culture in the room mattered as much as the mechanics: challenge was never personal, ideas were never red-lighted while being born, and the manager’s job was to make the risk safe to take rather than to prevent it — the condition Catmull identifies as the foundation of any self-correcting creative organization [5]. The transferable lesson. Every late program is late inside a frame of assumptions it can no longer see. The challenge process is a repeatable, one-day instrument for seeing the frame: measure the gap honestly, refuse the easy exits, surface the assumptions, ask why until a reason fails, and rebuild the schedule around what the failure opens up — within seven days, while the team still owns it. -- 23 of 24 -- › Three teams, three breakthroughs › › › © 2026 lateralworks Page 24 Sources References [1] lateralworks. “Introduction to Critical Thinking.” Client seminar and workshop materials, best practices of fast teams series, 2014–2022. Includes the challenge, concept triangle, random entry, and escape provocation techniques, workshop artifacts, and the three case records documented in this paper. [2] de Bono, E. Lateral Thinking: Creativity Step by Step. Harper and Row, 1970. [3] de Bono, E. Serious Creativity: Using the Power of Lateral Thinking to Create New Ideas. HarperBusiness, 1992. [4] lateralworks. “Breakthroughs by Challenging Assumptions.” lateralworks.com, January 2019. https://lateralworks.com/ideas/2019/1/16/breakthroughs-by-challenging-assumptions [5] Catmull, E., with Wallace, A. Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration. Random House, 2014. [6] lateralworks. “The Challenge Game.” lateralworks.com. https://lateralworks.com/ideas/the-challenge-game [7] lateralworks. “10 Best Practices of Fast Teams.” Whitepaper, lateralworks.com. https://lateralworks.com/papers/10-best-practices-of-fast-teams.pdf [8] Churchman, C. W. The Systems Approach. Delacorte Press, 1968. [9] lateralworks. “My Schedule Keeps Slipping…” lateralworks.com. https://lateralworks.com/ideas/my-schedule-keeps-slipping [10] lateralworks. Program archive: fastProject wigglecharts, workshop photographs, flip charts, and schedule records from the client engagement, 2014–2015. Client identity withheld by agreement. [11] Kinzer, S. The Brothers: John Foster Dulles, Allen Dulles, and Their Secret World War. Times Books, 2013. On confirmation bias, groupthink, and belief as identity. A note on anonymization. The client for all three engagements is a major disk-drive storage company operating at extremely high volume under aggressive time-to-market pressure. Individual names have been removed from the text and blurred in chart artifacts; workshop photographs are reproduced as taken. Program codenames (Watson, Rainier, Slider Bias) are internal designations with no external meaning and are retained for readability. Technology names that could identify the client or its partners have been generalized in the text. -- 24 of 24 --

Client Projects·Case study·Data storage / disk drives

Three teams, three breakthroughs

How the challenge process found technical and schedule breakthroughs inside three storage development programs

Core thesis. A schedule gap is not evidence that requirements must be relaxed. Treated correctly, the gap is raw material: the pressure that forces a team to surface its assumptions, challenge them one by one, and discover ways of working it had quietly classified as impossible.

July 22, 2026·24 pages