Two Monday mornings. Same industry. Completely different realities.
The first Monday: A senior engineering director at a large semiconductor company arrives to a calendar packed with program management checkpoints, cross-functional reviews, and a tapeout readiness gate. A team of 180 engineers is executing against a specification freeze that happened six weeks ago. Every change request goes through a formal review board. The RTL has been frozen. Physical design is running timing closure on tens of timing scenarios. The day will be organized, structured, and governed by process — because at this scale, it has to be. Even when surprises hit — a silicon bug, late updates to the TO model — the response follows a playbook.
The second Monday: A founder-engineer at a 12-person chip startup begins a day with no fixed agenda. Whatever passed for a spec last Friday has already shifted based on a new customer conversation. Three engineers are working in parallel on blocks that will need to interface in ways nobody has fully defined yet. He will make fifteen significant technical decisions before noon — and implement half of them himself. Most are made under uncertainty, most are irreversible in the short term. He is moving fast because he has no choice. Standing still costs runway.
I have lived the first Monday. More than twenty years in chip design, building mixed-signal teams that scaled from small to large at one of the world's largest consumer electronics companies. I know what precision looks like from the inside — the discipline it takes, the overhead it costs.
Now I am living the second Monday — building a startup with a team of four. Different domain, same operating system: judgment, speed, and the hope that shared context holds long enough to ship. And through both, I have watched engineering organizations at every scale navigate the same tension between these two modes.
What strikes me most, looking back, is not how different those two Mondays feel. It is how they represent two genuinely different operating systems — two distinct ways that engineering organizations process reality, make decisions, and coordinate work.
Both systems work. Both systems have deep structural logic. And increasingly, both are under pressure from a world that seems to demand the other one simultaneously.
Large Organizations Run on Precision
When Apple's head of silicon, Johny Srouji, reflected on building the company's chip design organization, he described starting with a team of roughly 40 to 50 engineers.[^1] That team grew to thousands. What made that scaling possible was not simply hiring. It was architecture — specifically, what Srouji described as a unified memory architecture designed to be scalable across products, letting Apple reuse core design elements from iPhone to iPad to Mac.[^2]
That is the first principle of large-organization engineering: precision enables scale. When you have hundreds of engineers working on a single SoC, you cannot rely on individuals remembering what they agreed to last Tuesday. You need codified specifications, formal handoff protocols, and review gates that catch misalignment before it propagates. The system itself has to carry the intent — because no single human can.
The discipline this creates is real and consequential. The design methodology for major processor programs involves what engineers describe as a progressive specification freeze: as the design matures from architecture to microarchitecture to RTL, the cost of changing a decision rises dramatically. By the time RTL blocks are coming in, an architecture-level change is rare and extremely expensive — involving new RTL, new debugging, new verification.[^3] This is not bureaucracy for its own sake. It is an engineering response to the physics of large-scale coordination. The later you catch something, the more work must be undone.
Timing closure illustrates this principle in quantitative terms. At advanced nodes, timing closure — the process of ensuring every path in the design meets its timing constraints — consumes roughly 30 percent of the physical implementation design schedule.[^4] For a large SoC, this translates to hundreds of timing scenarios that must be analyzed, with engineering change orders (ECOs) to fix violations. The ECO iteration itself is a structured, disciplined process: identify the violation, propose a fix, verify the fix doesn't create new violations, propagate the change. At Samsung's advanced process nodes, the improvement in ECO management from better tooling and methodology translated directly to 50 percent reduction in ECO iterations and measurable gains across setup and hold violation counts.[^5] That improvement was possible only because the process was precise enough to measure.
The urgency of this discipline is captured by an uncomfortable data point from DARPA's CRAFT (Circuit Realization At Faster Timescales) program. DARPA launched CRAFT explicitly because the current reality of advanced SoC design — two or more years and more than a hundred million dollars — is untenable for the pace of modern technology. The program aims to compress the design and verification cycle by an order of magnitude.[^6] The fact that this compression requires a dedicated government program signals something important: the precision required for large-scale chip design has made it structurally slow, and that slowness has real consequences for national technology competitiveness.
The insight from large organizations is not that precision is the enemy of innovation. It is that precision is what allows innovation to survive scale. Without it, a team of hundreds produces not a great chip but an expensive chaos.
"Precision enables scale, but it slows adaptation."
---
Startups Run on Judgment
At a small engineering team, the constraint is different. You do not have enough people to build every process, every review gate, every formal handoff protocol. You have four or twelve or twenty engineers who need to move from idea to silicon in a window measured in months, not years, on a budget that cannot absorb the cost of methodological elegance.
I know this version too.
"We are always late. We are a team of four building what teams of forty build."
That is not a complaint — it is the design point. Startups in chip design have to be that way because the alternative is burning runway on overhead before the core insight is validated.
What substitutes for process in small teams is judgment. The experienced engineer who carries the system-level intent in her head, who can make the right call on interface voltage thresholds without a three-week review cycle, who recognizes the downstream implication of a design change before it propagates into problems. This is founder-mode engineering: fast, intuition-driven, high-variance.
The data on small teams confirms this model's productivity advantage. Teams in the five-to-nine-person range consistently show lower coordination overhead, faster time-to-market, and higher per-engineer output compared to larger teams — a mathematical consequence of the fact that communication paths grow exponentially with team size. Five engineers have ten communication paths; fifteen engineers have 105. Small teams bypass most of that complexity through proximity and shared context.
AI tools have sharpened this advantage recently. Individual coding productivity in software has increased substantially with the deployment of AI assistants — McKinsey's research shows developers completing tasks significantly faster with generative AI, and broader industry data suggests 30-60 percent time savings on coding, testing, and documentation tasks.[^7] The effect on minimum viable team size is directional: work that previously required three engineers may now require two. The lean team gets leaner, the judgment advantages compound, and the startup operating system runs faster.
McKinsey research also identifies a structural pattern that frames the startup tension precisely: 78 percent of companies that successfully achieve product-market fit fail to scale.[^8] The failure mode is not running out of good ideas. It is that the operating system that found product-market fit — built on founder judgment, informal coordination, rapid iteration — cannot absorb the coordination complexity that comes with growth. The judgment operating system is not designed for large-team coordination. It was not meant to be.
"Judgment enables speed, but it struggles with complexity."
The Tension That Won't Resolve
Engineering leaders live inside this tension constantly. The startup founder who needs to add process without losing velocity. The large-company VP who needs to move faster without losing discipline. The mid-scale team that is too big to rely on judgment alone and too small to afford the overhead of full precision.
This tension is not new. What is new is its intensity.
Three forces are converging to make the precision-versus-judgment tradeoff harder than it has ever been.
First: the complexity curve is steeper. At 3nm and below, chip design complexity is not just incrementally harder than previous generations — it is qualitatively different. More timing scenarios, more process variation effects, more physical phenomena that require explicit specification and verification. The coordination requirements that precision methodology was designed to handle have grown another order of magnitude in the past five years. A team that handled 7nm with disciplined precision finds that the same discipline applied to 3nm produces insufficient coverage. More precision is required, at the same time that faster delivery is demanded.
Second: the time-to-market window is compressing. Markets that tolerated eighteen-month chip design cycles are now responding to competitors with twelve-month cycles. The chiplet revolution, while expanding design flexibility, adds new coordination demands: power delivery across die boundaries, cross-die timing closure, interface specification between chiplets from different teams or vendors. Gartner projected that 30 percent of all advanced node processors would use chiplet-based architectures by 2025.[^9] Each new die boundary is a new coordination surface. More coordination surfaces, shorter cycles, higher precision requirements — simultaneously.
Third: the software comparison is becoming unavoidable. The engineering systems that manage software complexity at scale — the aviation industry's DO-178C discipline that governs software like the Boeing 787's 14 million lines of code[^10], the automotive world's emerging equivalent for vehicles that now routinely exceed 100 million lines of code[^11] — represent decades of accumulated learning about how to operate with both precision and speed at complexity scales that hardware engineering is now approaching. Automotive is actively borrowing from aviation's playbook as software complexity in cars has grown by an order of magnitude in a decade. Hardware is watching this and wondering what the equivalent looks like for silicon.
The tension is also visible in pure organizational terms. Teams lose meaningful productive time navigating multiple coordination tools and handoff workflows — industry analysis suggests crossing the 20 percent coordination overhead threshold is a signal that an engineering organization is not ready to scale.[^12] The organizational literature on agile transformations offers some data on what good looks like: McKinsey's research across sectors suggests that properly structured agile operating models can deliver a fivefold to tenfold increase in speed of decision-making alongside 10-30 percent improvements in operational performance.[^13] But the key word is "properly structured." An agile model that simply removes process without replacing it with coordinated judgment does not deliver these outcomes. It delivers the local optimization trap at scale.
The strategic insight from BCG and McKinsey on platform operating models is elegant in theory: "loosely coupled, tightly aligned" — teams that can execute autonomously while remaining oriented toward shared goals.[^14] This is the synthesis that both operating systems are groping toward. But the synthesis requires something that most engineering organizations do not currently have: an orchestration layer that holds the shared intent together while teams move independently. Without that layer, "loosely coupled, tightly aligned" becomes "loosely coupled, diverging" — which is precisely what the precision operating system's review gates and specification freezes were designed to prevent.
Neither operating system alone is sufficient anymore. The precision operating system is too slow for modern market dynamics. The judgment operating system breaks down before it can scale. Engineering leaders who recognize this are not looking for more process or less process. They are looking for a different kind of infrastructure — one that enables the speed of judgment while maintaining the coherence of precision.
What does that infrastructure look like? That is not a question with a simple answer yet. But it is the right question.
---
Which Operating System Are You Running?
Most engineering organizations claim that they run "both" — which usually means they are running whichever one feels more urgent this week, and switching between them without intention.
The startup founder adds process checkpoints when a misalignment costs three weeks. The large company VP empowers a small team to move like a startup, then watches the misalignment compound when the team hands off to the broader organization. The mid-scale team invents its own hybrid, usually based on what its most senior engineers were trained on at previous jobs.
None of this is wrong. It is adaptive. But it is also invisible — which means the costs are absorbed without being understood, and the choices are made without being recognized as choices.
The precision operating system's costs are visible: slow cycle times, heavy meeting overhead, change control friction. The judgment operating system's costs are visible too: late-stage surprises, expensive rework when the intuition was wrong, coordination breakdown when the team grows past the range where informal shared understanding holds.
What is less visible is the cost of switching between them without intention — the overhead of navigating an organization that has not decided which operating system it is running, and therefore cannot optimize either one.
This is the less-discussed dimension of engineering leadership. Not whether your team is technically excellent — most chip design teams are. Not whether your engineers are working hard — they always are. But whether the operating system your organization runs is matched to the complexity, scale, and speed requirements of the problems you are solving.
I find myself returning to a deeper question underneath all of this.
AI is beginning to change how engineering teams operate in ways that make this question newly urgent. Individual engineers are getting faster. Specific design tasks that previously required hours now require minutes. The judgment operating system's lean-team advantages are sharpening.
But individual acceleration is not the same as system coherence. And the precision operating system's fundamental problem — the overhead of maintaining shared understanding across large teams — has not been addressed by making each engineer faster.
If precision is the operating system of large organizations, and judgment is the operating system of startups — what is the operating system for AI-native engineering teams?
Not AI tools bolted onto the existing precision operating system, slowing it down with new integration overhead. Not AI tools that make the judgment operating system's individual contributors faster while leaving the coordination problem untouched.
Something genuinely different. An infrastructure that learns the intent of the design as it evolves, that keeps teams coherent without requiring the formal process overhead that precision demands, and that scales the judgment of the best engineers across a team rather than leaving it resident in individual heads.
What that looks like in practice — I think we are only beginning to understand. But the organizations that figure it out first will not choose between precision and speed. They will have found a way to have both.
[^1]: Johny Srouji, SVP Hardware Technologies, Apple, in CNBC interview with Josh Lipton and Steve Kovach, December 2023. "It was a very small team at the time, about 40 to 50 engineers. We have thousands of engineers [now]." Link
[^2]: Johny Srouji, Apple, CNBC, December 2023. "We built what we call the unified memory architecture that is scalable across products." Describing reuse across iPhone, iPad, Apple Watch, and Mac product lines. Link
[^3]: Industry characterization of progressive specification freeze in advanced IC design programs. At the RTL stage, architecture changes become rare and extremely expensive due to the cascading cost of redesign and reverification. Referenced in Semiconductor Engineering coverage of design methodology for complex SoCs. Link
[^4]: Electronic Specifier, "Timing closure & signoff reduces required ECO iterations." Timing closure encompasses roughly 30 percent of the physical implementation design schedule at advanced nodes. Link
[^5]: Synopsys and Samsung Foundry collaboration on design closure at 5nm to 3nm. Samsung achieved 50 percent reduction in ECO iterations and 77.28% reduction in setup violations using adaptive scenario compression. Link
[^6]: DARPA, "CRAFT: Circuit Realization At Faster Timescales," DARPA Research Programs. The CRAFT program targets a 10x reduction in design and verification effort, compressing advanced SoC development cycles from 2+ years and $100M+ investment toward months. Link
[^7]: McKinsey & Company, "Unleashing developer productivity with generative AI," McKinsey Insights, 2023-2024. Study of 40+ developers across the US and Asia found significant task-completion speed improvements with generative AI. Broader industry consensus: 30-60% time savings on coding, testing, and documentation tasks. Link
[^8]: McKinsey UK, "The scale-up conundrum: Evolving startups from founder-led growth to industrialised scalability," April 2025. Research suggests 78% of companies that achieve product-market fit fail to scale, often because the founder-judgment operating model cannot absorb growing coordination complexity. Link
[^9]: Gartner projection (2024): 30% of all advanced node processors would use chiplet-based architecture by 2025. Cited in Semiconductor Digest and Keysight industry coverage. Link
[^10]: MIT Technology Review, "Many Cars Have a Hundred Million Lines of Code," 2012. The Boeing 787 Dreamliner contains approximately 14 million lines of code — a widely cited benchmark for aviation software complexity. Also referenced in Visual Capitalist's "How Many Millions of Lines of Code Does It Take?" infographic. Link
[^11]: Porsche AG, "A Modern Car Runs on 100 Million Lines of Code," Medium, 2021. Modern vehicles exceed 100 million lines of code and are projected to require 200-300 million lines in the near future. IEEE Spectrum similarly documents automotive software complexity exceeding aviation counterparts. Link
[^12]: CTO Executive Insights, "How to Scale Engineering Teams," 2024. "Teams losing more than 20% of productive time to coordination overhead aren't ready to scale." Directionally consistent with Stripe's 2024 Developer Report: 96% of engineering leaders say teams pass 50 developers before coordination overhead exceeds coding time. Link
[^13]: McKinsey & Company, "The impact of agility: How to shape your organization to compete," McKinsey Organizational Performance, 2021-2024. Properly structured agile operating models deliver 5-10x increase in speed and decision-making speed; 10-30% improvement in customer satisfaction, operational performance, and efficiency. Link
[^14]: The "loosely coupled, tightly aligned" principle appears across BCG, McKinsey, and Netflix's engineering operating model literature as the aspiration for mature engineering organizations — teams that execute autonomously while remaining coherent at the system level. Netflix's Director of Engineering: "We want our teams and services to be tightly aligned, but loosely coupled." O'Reilly Radar. Link
---
Follow AIDAChip
- LinkedIn - Website
---
About the Author
Khaled Alashmouny is the Founder of AIDAChip. With 20+ years in semiconductors -- including 13 years leading analog/mixed-signal design teams at Apple -- he has 9 IEEE publications and 7 patents. He has delivered GenAI workshops to hundreds of engineers at leading technology companies. His work focuses on the intersection of AI and chip design coordination, addressing the systemic productivity challenges that the semiconductor industry has struggled with for decades.
About AIDAChip
Engineering, Aligned. AIDAChip is building the first AI-native orchestration layer for chip design -- a Multiplayer AI platform that spans intent, knowledge, and execution across all vendors and teams. Rather than optimizing individual tools, AIDAChip coordinates the system: keeping engineers, specifications, and decisions aligned throughout the design lifecycle.