Abstract

Most semiconductor organizations spread their best engineers across three, four, or five projects at once, on the theory that high utilization equals high productivity. Four decades of research says the opposite. Past two concurrent projects, context-switching consumes 40 to 75 percent of an engineer’s working time, queue delays compound at every milestone gate, and the calendar slips by months — not weeks. This paper synthesizes evidence from Gerald Weinberg’s foundational research on engineering productivity, the Carnegie Mellon Software Engineering Institute’s applied validation, Frederick Brooks’s work on software project staffing, Donald Reinertsen’s queueing-theory analysis of product development, Clark and Wheelwright’s heavyweight-team studies at Harvard Business School, and McKinsey’s 2024 product-team survey data. The conclusion converges from independent streams: one to two projects per engineer is the maximum sustainable load for complex new product development. Beyond two, both speed and quality degrade in a nonlinear pattern that hits semiconductor NPI especially hard, where cycle times are long, interdependencies are deep, and the cost of delay is measured in quarters of lost revenue. The same arithmetic operates at the organizational level. Steve Jobs’s 1997 portfolio cut at Apple, Goldratt’s Theory of Constraints, and Smith and Reinertsen’s discipline around the fuzzy front end all converge from different angles: do fewer things, with more dedicated people, and every program ships faster. For semiconductor leadership teams, the prescription is structural — transition from shared functional assignments to dedicated cross-functional product delivery teams, codify the project-load limit, and govern the portfolio explicitly so creeping load doesn’t undo the discipline. lateralworks engagement data across two decades of programs supports the argument: organizations that adopt the dedicated team model and govern the portfolio against cost of delay deliver to original calendar at substantially higher rates than peers that do not.

Section one — The hidden tax— context switching

A semiconductor engineer holds a complex mental model. A process engineer tracking a new integration flow keeps in working memory the interactions among hundreds of process steps, material properties, equipment constraints, and device specifications. A device engineer characterizing a novel memory cell tracks electrical parameters, endurance, retention, and reliability margins simultaneously. Asking that engineer to switch contexts is not the same as asking a knowledge worker to switch email tabs. The mental reload cost is real, and it scales with the size of the model that has to come back online.

Section one The hidden tax—context switching Most semiconductor organizations treat engineers as fungible capacity. The reasoning is intuitive: if an engineer is waiting on wafers from the fab, they should be working on the next project’s design review. Idle hands are wasted capacity. The reasoning ignores a fact about human cognition. A computer can save and restore state in microseconds. A human engineer has to mentally unload one project and reload another. The cost of that swap is real, and it isn’t small. Weinberg’s foundational research In 1992, Gerald Weinberg quantified the penalty in Quality Software Management: Systems Thinking. His model, drawn from decades of observation across engineering organizations, looks like this: at one project, an engineer puts 100 percent of their time into the work. At two, productive capacity drops to 80 percent and 20 percent goes to switching overhead. At three, productive capacity is 60 percent and switching consumes 40. At five, only 20 percent of working time is productive; 75 percent is the cost of swapping contexts. Figure 1. Productive time vs context-switching loss by number of simultaneous projects. The relationship is nonlinear: a second project doesn’t cost 10 or 15 percent of available time, it costs a full 20. By five projects, only 5 percent of working time goes to each project. Source: Weinberg, 1992. The relationship is nonlinear. A second project doesn’t cost 10 or 15 percent — it costs a full 20, dropping per-project capacity from 100 to 40. By five concurrent projects, the engineer is putting only 5 percent of their time into each one. The other 75 percent is overhead. Carnegie Mellon SEI validation The Software Engineering Institute at Carnegie Mellon validated Weinberg’s model in applied engineering settings. Their research confirmed the curve and added a second finding: engineers carrying multiple projects don’t only slow down. They produce more defects, miss more tasks, and disengage from the

collaborative problem-solving that complex technical work depends on. In semiconductor NPI, where a missed yield risk or an incomplete qualification plan can delay a customer milestone by a full quarter, the quality penalty compounds the schedule penalty. The connection to Brooks’s Law The same pattern appears in Frederick Brooks’s 1975 study of software development at IBM, where he observed that adding manpower to a late project makes it later. Brooks’s Law and Weinberg’s switching penalty are the same physical phenomenon described from two angles. Brooks looked at what happens when you increase headcount on a project; Weinberg looked at what happens when you split each engineer’s attention. Both end at the same place: more bodies on more things produces less output, not more, when the work is complex enough to require sustained focus. Key finding. Context switching does not merely slow engineers down — it degrades the quality of their work product. In semiconductor NPI, where a missed yield risk or an incomplete qualification plan can delay a customer milestone by a full quarter, the quality penalty compounds the schedule impact.

Section two — The cognitive science of focused work

The engineering observations Weinberg and the CMU SEI documented are consistent with decades of cognitive psychology research. Switching tasks is not free. It involves two distinct cognitive operations — deciding to switch, and reactivating a different set of rules — and both consume measurable time and mental energy. The penalty is sharper for engineers whose mental models are unusually large.

Section two The cognitive science of focused work Rubinstein, Meyer, and Evans (2001) showed that every task switch involves two distinct cognitive operations: goal shifting (deciding to switch) and rule activation (deactivating one set of cognitive rules and engaging another). Both consume measurable time and mental energy. Research published in the Journal of Experimental Psychology found that switching between tasks costs the average knowledge worker 20 to 40 percent of their productive capacity. The American Psychological Association has documented that roughly 2 percent of the population can effectively multitask; the remaining 98 percent show measurable performance degradation when working across multiple complex contexts at once. The penalty is sharper for semiconductor engineers because the mental models they maintain are unusually large. A process engineer working a new integration flow holds in working memory the interactions among hundreds of process steps, material properties, equipment constraints, and device specifications. A device engineer characterizing a novel memory cell tracks electrical parameters, endurance data, retention metrics, and reliability margins simultaneously. When that engineer is interrupted to switch to a different project — different process variant, different design rules, different critical path — the cost of rebuilding the mental model is not the same as a knowledge worker switching email tabs. Multitaskers make up to 50 percent more errors than those holding focus on a single complex task. In semiconductor NPI, where errors propagate through long manufacturing cycles, that error rate translates directly into respins, qualification delays, and customer schedule slip. Goldratt and the Theory of Constraints Eliyahu Goldratt reached the same conclusion from a different starting point. Goldratt observed that multitasking is the silent throughput killer in any system where work units are interdependent. His prescription — limit work-in-progress, focus on the bottleneck, finish what you start — is the operational complement to Weinberg’s quantification of why. The two frameworks reach the same place: the way to accelerate complex work is not to start more of it, but to finish what is already in flight.

Section three — The economic model: Reinertsen’s queueing theory

Reinertsen’s contribution was to apply the math of queueing theory — the same math that governs telecommunications networks and computer operating systems — to product development. The result is a single unforgiving curve: when processes with variability are loaded toward 100 percent capacity utilization, queue times grow exponentially, not linearly. This is what makes overloading engineers so destructive. Small delays don’t add. They compound.

Section three The economic model: Reinertsen’s queueing theory Donald Reinertsen’s Principles of Product Development Flow (2009) provides the mathematical framework that explains why overloading engineers creates such disproportionate schedule damage. The math under the curve is Little’s Law: average work-in-progress equals average throughput times average cycle time. Hold throughput constant, and cutting WIP cuts cycle time proportionally. Add WIP back, and cycle time stretches. The queue curve is what happens when you push utilization toward 100 percent in a system with any variability at all — variability creates queue buildup, and at high utilization the queue cannot drain. Figure 2. Queue time vs resource utilization (M/M/1 queueing model). The curve is exponential, not linear: an engineer at 90 percent utilization waits roughly 9x longer in queue than one at 50 percent. Engineers loaded with three or more concurrent projects operate in the 85–95 percent zone where small variability cascades into large schedule slip. Source: based on Reinertsen, 2009. Engineers carrying three to five concurrent projects are operating at 85 to 100 percent capacity utilization. At those levels, any variability in task duration — a wafer lot that takes longer than expected, a supplier delay, an unexpected test failure — creates a queue that propagates across all of the engineer’s projects. The engineer becomes the bottleneck, and every project competes for fractional attention. Cost of delay versus utilization Reinertsen’s deeper point is that the right performance metric in product development is not utilization but cost of delay. In semiconductor NPI, the cost is severe. A one-quarter delay can decide whether a product wins or loses a design socket worth tens or hundreds of millions in lifetime revenue. The "savings" from running engineers at 100 percent utilization are dwarfed by the schedule cost the overload creates.

Reinertsen’s prescription is to keep resource utilization below 80 percent — ideally 60 to 70 percent — to preserve slack for absorbing variability without queue buildup. In human terms, that is the one-to-two-project optimum: an engineer with one primary project and limited secondary responsibilities operates in the productive zone where queue times stay manageable and schedule pull-in is achievable. The same logic underlies Smith and Reinertsen’s earlier work on the fuzzy front end — the period before a full development team forms is itself a queueing system, and managing it as a focused, time-boxed project is what prevents the lost months from showing up later as compression on engineering. lateralworks documented this pattern in detail in a companion methodology paper.

Section four — Case study evidence: dedicated resources and faster delivery

The research evidence comes from four streams. Each examined a different population — software engineers, hardware product teams, fintech delivery groups, music-streaming squads — and reached the same conclusion: dedicated resources outperform shared resources on speed, predictability, and quality. Section 4 walks each stream in turn, then closes with the organizational analogue: Steve Jobs’s 1997 portfolio cut at Apple.

Section four Case study evidence: dedicated resources, faster delivery Figure 3. The scope of FTTM portfolio decisions. This paper sits in Project Execution — specifically the engineer-level project load and team-level dedication that determines how fast a funded program reaches first customer ship. Source: lateralworks FTTM methodology. 4.1 Clark and Wheelwright: heavyweight product development teams The most directly relevant research for semiconductor organizations comes from Kim Clark and Steven Wheelwright at Harvard Business School. Their 1992 study in California Management Review examined product development team structures across automotive, semiconductor, and electronics firms. Clark and Wheelwright identified four team archetypes — functional, lightweight, heavyweight, and autonomous — and found that heavyweight teams consistently outperformed lightweight and functional structures on speed and quality. The defining characteristics of heavyweight teams map directly onto the dedicated-resource model: a strong, dedicated team leader with direct customer contact and authority to make cross-functional tradeoffs; team members dedicated to the project rather than split across functional assignments; team-level ownership of full scope from concept through manufacturing release. In their six-year worldwide study, Wheelwright and Clark documented 30 to 50 percent faster development cycle times in organizations using heavyweight team structures. Critically, their case base included Applied Materials — a semiconductor equipment company — establishing direct relevance to the industry. 4.2 McKinsey: 100 percent dedicated teams and delivery predictability McKinsey’s 2024 research on product-team effectiveness, drawing on hundreds of teams globally, confirmed that teams with 100 percent dedicated members who don’t context-switch between projects build

consistency in their estimates, and their velocity and throughput improve. A global fintech the firm studied moved to multidisciplinary teams with dedicated talent from product, technology, and operations. Within three months of the transition, delivery predictability moved from 60 to 95 percent. The shift came almost entirely from eliminating resource-sharing and context switching. 4.3 The Spotify model: autonomous squads Spotify’s well-documented organizational model offers a scaled implementation case. Organizing development into autonomous, cross-functional squads — each dedicated to a single product area with no shared resources — produced a reported 20 percent reduction in delivery time and a 20 percent gain in employee satisfaction. The dedication and ownership, not the resource pooling, drove both. 4.4 Steve Jobs and Apple: the portfolio-level imperative Figure 4. Portfolio decision-making flow. Strategic and economic filters determine what enters the pipeline; ordering inside the pipeline determines what gets attention; learning from outcomes feeds back into the next cycle. Apple’s 1997 portfolio cut is the canonical example of aggressive filtering at the entry stage. Source: lateralworks FTTM portfolio methodology. The research above operates at the individual level: limit each engineer to one or two projects and productivity rises. There is a parallel principle at the organizational level — limit the number of products the company pursues, and the entire engineering organization accelerates. The cleanest demonstration came from Steve Jobs’s return to Apple in 1997. Apple was producing a dozen versions of the Macintosh along with peripherals, printers, and failed experiments like the Newton PDA and the Pippin game console. Multiple teams with overlapping mandates competed for engineering talent. No product received the focus required to be excellent. After several weeks of product reviews, Jobs drew a two-by-two grid on a whiteboard. Columns: Consumer, Pro. Rows: Desktop, Portable. Apple would make four products, one per quadrant, and cancel everything else. Walter Isaacson recorded Jobs’s framing: Deciding what not to do is as important as deciding what to do. That’s true for companies, and it’s true for products. Jobs reinforced the discipline annually — gathering his top 100 leaders, soliciting their ten most important priorities, then slashing seven, on the principle that Apple could only do three things well at once.

The result was structural. Cutting 70 percent of the portfolio did not just reduce overhead; it changed the resource dynamics. Apple’s best engineers, previously scattered across a dozen mediocre products, were now concentrated on four. Cycle times compressed: major new product revisions began shipping every nine months instead of eighteen. The iMac, the first product of the focused strategy, shipped within a year and defined a category. The Apple case ties the threads together. Weinberg and CMU SEI explain the cost when individual engineers carry too many projects. Reinertsen explains the queue-time explosion when shared resources run at high utilization. Brooks’s Law explains why throwing more bodies at the problem makes it worse. Jobs demonstrated the organizational solution: with a fixed pool of engineering talent, the surest way to accelerate every product is to reduce the number of products competing for that talent. Fewer products means more dedicated attention per product, less context-switching at the individual level, shorter queues at the organizational level, and faster cycle times across the board. For semiconductor organizations, the lesson is direct. Pursuing every plausible product variant, technology node, or market segment looks attractive in isolation — each opportunity has independent value. But when the same finite pool of process engineers, device physicists, and design teams is spread across all of them, every program slows down, every milestone slips, and the organization delivers many products late rather than a few products on time. The discipline to define a focused portfolio — and to protect that focus against the constant pressure to add "just one more" — is the organizational complement to the individual project-load limit.

On focus What not to do Deciding what not to do is as important as deciding what to do. — Steve Jobs Recounted in Walter Isaacson, Steve Jobs (2011)

Section five — Application to semiconductor NPI

Three structural ingredients distinguish a dedicated product team from a shared functional one: dedication itself (the one-to-two-project limit), explicit decision rights inside the team (so cross-functional tradeoffs don’t escalate upstream), and portfolio-level ownership above the team (so creeping load doesn’t silently undo the dedication). All three matter. Without dedication, capacity bleeds to context switching. Without decision rights, even dedicated teams stall in committee. Without portfolio ownership, project starts pile up faster than the organization can finish them.

Section five Application to semiconductor NPI The evidence converges on a clear conclusion: dedicated resources organized around products, not functions, produce faster and higher-quality new product development outcomes. For semiconductor organizations, the implication is structural — transition from shared functional assignments to dedicated cross-functional product teams, with named portfolio ownership above them and named decision rights inside them. 5.1 Why semiconductors are especially vulnerable Semiconductor NPI programs have several characteristics that make them especially susceptible to engineer overloading. Development cycles are long — typically 18 to 36 months from concept to production release — so context-switching delays compound across many months and many milestone gates. The work is deeply interdependent across functional disciplines: process development, device engineering, integration, design, and product qualification. A delay in one function creates queue delays in all the others. Manufacturing variability is inherent to the work — wafer processing, material properties, equipment performance — so the queue-time explosion Reinertsen models is not theoretical risk but daily operational reality. Semiconductor NPI now operates against external dates: customer platform launches, competitive technology windows. Missing a milestone doesn’t just push revenue out by a quarter. It can lose the design socket to a competitor outright, or close the differentiation window that justified the program in the first place. The cost of delay in this context is measured not in incremental development expense but in hundreds of millions in foregone lifetime product revenue.

Figure 5. Portfolio ownership: who decides what to start, in what order, against what economic and resource constraints. Strategic fit and economic test filter what enters the pipeline; the 80/20 cost–benefit logic determines start order; resource constraints — including the one-to-two-project-per-engineer limit — govern how many programs can be in flight at once. 5.2 Decision rights inside the dedicated team A dedicated team is necessary but not sufficient. Without explicit decision rights inside the team, the dedicated structure fragments back into committee dynamics — every cross-functional tradeoff goes back upstream for resolution, and the team’s structural advantage disappears. Figure 6. The IRADP framework adapted from Rogers and Blenko’s RAPID work. Inside a dedicated product delivery team, the team lead occupies Decides for cross-functional tradeoffs the team owns; functional managers occupy Decides for the small number of decisions that genuinely cross product boundaries. Source: Rogers & Blenko, HBR 2006, adapted by lateralworks.

The IRADP framework adapted from Rogers and Blenko’s RAPID work makes the structure explicit: who provides Input (consulted, involved in implementation), who Recommends (gathers data, prepares proposals, builds buy-in), who Agrees (has veto power, triggers debate, can escalate), who Decides (makes the call, is accountable, commits the organization), and who Performs (executes the decision). Naming each role removes the ambiguity that makes shared-resource organizations slow. Inside a dedicated product delivery team, the team lead occupies Decides for cross-functional tradeoffs the team owns; functional managers occupy Decides for the small number of decisions that genuinely cross product boundaries. The 80/20 split between team-owned decisions and function-owned decisions is what operationalizes the boundary between team autonomy and functional management. This is the missing structural piece in many "dedicated team" rollouts. Companies form the team, dedicate the people, and discover that decisions still escalate to functional VPs — because nobody wrote down who decides what. Once IRADP is explicit, the team can move at its own velocity, and the functional layer’s role is clear: accountable for capability development, not for individual project decisions. 5.3 Time-to-market impact Three acceleration effects compound when engineers are dedicated to a single product family at the one-to-two-project limit. First, the 20 to 40 percent of capacity currently lost to context switching is recovered and applied to productive engineering work. Second, queue delays between milestone gates are eliminated, because engineers are not competing for fractional attention across multiple products. Third, deeper product knowledge from sustained focus produces better technical decisions, fewer errors, and more effective cross-functional collaboration — all of which contribute to schedule pull-in rather than schedule slip. Based on the research evidence and case-study precedents, the combined effect is a 25 to 40 percent acceleration in NPI cycle time — equivalent to 6 to 10 months on a typical 24-month semiconductor development program. In competitive markets where technology windows are finite and every quarter of delay reduces strategic position, that acceleration is not incremental. It is the difference between leading a generation and following one.

Section six — Recommendations

Four prescriptions follow from the research. Each is structural, not aspirational — codifiable as policy, observable in operating practice, and directly tied to the cycle-time outcome the organization is trying to produce. The recommendations apply to any semiconductor organization transitioning from shared functional assignments to dedicated cross-functional product teams.

Section six Recommendations Figure 7. The portfolio modeling loop. Strategic fit and economic test eliminate projects below the line; the constrained model prioritizes starts against real resources, budgets, risks, and dependencies. The loop iterates as time-phased information arrives — macro plans for resources, business plans for ROI and cost of delay. This is the operational discipline that prevents creeping load. 6.1 Establish the one-to-two-project maximum Every engineer on a dedicated product team should carry no more than two concurrent project assignments, with one designated primary. This is not a guideline — it is the research-backed optimum for preserving productive capacity and the quality of complex engineering work. Codify the limit as a non-negotiable organizational norm, embedded in resource planning processes and management operating systems. 6.2 Dedicate embedded leads to single product families Cross-functional team leads — whether organized as triads, squads, or heavyweight teams — should be dedicated to a single product or technology workstream. They should not be shared across multiple concurrent programs. Both the Clark and Wheelwright research and the McKinsey data show that this single dedication is the highest-leverage structural change an organization can make to accelerate product development. 6.3 Protect against creeping load Organizations that establish project-load limits often erode them incrementally. A small side task here, a quick analysis there, a brief consultation on a third workstream — each insignificant in isolation, collectively pushing engineers back into the three-plus project zone where switching costs dominate. Team leaders must monitor and protect their team’s focus actively. The weekly planning cycle is the natural checkpoint; the modeling-flow loop above (strategic fit → economic test → prioritize starts → execute → iterate) is the

governance discipline that keeps creeping load from becoming the new normal. 6.4 Measure cost of delay, not utilization Following Reinertsen, shift the primary performance metric from resource utilization (how busy are our engineers?) to cost of delay (what is the revenue impact of each week of schedule slip?). When the organization sees that running engineers at 100 percent utilization creates queue delays worth millions in lost or delayed revenue, the case for dedicated resources stops being a debate and becomes self-evident. lateralworks engagement data across two decades of semiconductor and systems-product programs supports the claim: organizations that adopt the dedicated team model and govern the portfolio against cost of delay deliver to original calendar at substantially higher rates than peers that do not.

Section seven

Conclusion

The evidence is clear and converges from multiple independent research streams across four decades. The arithmetic does not change with industry, with technology, or with management style. What changes is whether the organization chooses to act on it.

Section seven

Conclusion

Engineers on one to two projects retain 80 to 100 percent of their productive capacity. Engineers on three or more lose 40 to 75 percent to context-switching overhead. The losses are not only time. They include quality degradation, error propagation, queue delays, and compounding schedule slip. For semiconductor development programs where the cost of delay is measured in quarters of strategic position and narrowing market windows, the imperative is unambiguous: dedicate engineers to product and technology workstreams, limit concurrent project assignments to two, and protect that focus as a first-order strategic priority. The dedicated product team model implements the principle structurally — cross-functional teams aligned to each product or technology workstream, with clear ownership, accountable leads, and explicit decision rights. The research base in this paper provides the empirical foundation for the transition. The discipline to sustain it is the work of leadership. More dedicated resources equals faster time to market. The research is unequivocal. The question is not whether to dedicate resources to product teams — it is how quickly the transition can be executed.

R Sources

References

  1. The argument in this paper draws on four streams of research, each independently developed but reaching the same conclusion. Citations below are listed in order of first appearance in the body. Reference 9 cross-links to the companion lateralworks methodology paper on the fuzzy front end; reference 16 represents lateralworks’ own engagement data across two decades of semiconductor and systems-product programs. Sources References
  2. Weinberg, G. M. Quality Software Management: Systems Thinking. Dorset House Publishing, 1992.
  3. Waits, T. "Addressing the Detrimental Effects of Context Switching with DevOps." Carnegie Mellon University, Software Engineering Institute Blog, 2015.
  4. Brooks, F. P. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, 1975 (anniversary edition 1995).
  5. Rubinstein, J. S., Meyer, D. E., and Evans, J. E. "Executive Control of Cognitive Processes in Task Switching." Journal of Experimental Psychology: Human Perception and Performance, 27(4), 2001, pp. 763–797.
  6. Goldratt, E. M. Critical Chain. North River Press, 1997.
  7. Reinertsen, D. G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
  8. Little, J. D. C. "A Proof for the Queuing Formula: L = λW." Operations Research, 9(3), 1961, pp. 383–387.
  9. Smith, P. G., and Reinertsen, D. G. Developing Products in Half the Time: New Rules, New Tools. 2nd edition, John Wiley & Sons, 1998.
  10. lateralworks. "Managing the Fuzzy Front End." Methodology paper, FTTM Best Practices Series, May 2026.
  11. Clark, K. B., and Wheelwright, S. C. "Organizing and Leading Heavyweight Development Teams." California Management Review, 34(3), 1992, pp. 9–28.
  12. Wheelwright, S. C., and Clark, K. B. Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency, and Quality. The Free Press, 1992.
  13. McKinsey & Company. "What Makes Product Teams Effective?" McKinsey Digital, 2024.
  14. Isaacson, W. Steve Jobs. Simon & Schuster, 2011, pp. 337–339.
  15. Isaacson, W. "The Real Leadership Lessons of Steve Jobs." Harvard Business Review, April 2012.
  16. Rogers, P., and Blenko, M. "Who Has the D? How Clear Decision Roles Enhance Organizational Performance." Harvard Business Review, January 2006.
  17. lateralworks. "Internal engagement database." Field observations across client programs in semiconductors, systems, medical devices, and industrial products, 2010–2026.