Engineering the Future: A Conversation with Krunal Patel by Milton D’Silva, Industrial Automation

A veteran TPM shares professional lessons from semiconductors, automotive, and consumer-electronics industries.

You’ve built a career leading hardware programs across three of the most complex industries – semiconductors, automotive, and consumer electronics. What inspired your journey?

Honestly, this path chose me. Looking back, what seemed like separate transitions was actually the development of a unique competitive positioning. Each transition happened because I was drawn to increasingly complex problems. What drew me to semiconductors was the foundational nature – every innovation in silicon becomes enabling technology for countless other industries.

How has working across such diverse hardware environments shaped your approach to program management and innovation?

Working across these industries taught me to think in systems and translate between disciplines. You develop pattern recognition for risks because you've encountered similar failure modes in different contexts. Automotive demands functional safety; consumer products require aggressive time-to-market. When you've navigated diverse product development lifecycles across industries, you develop pattern recognition for risk, when to apply which principles creates unique positioning.

The role of a Hardware Technical Program Manager (TPM) is often seen differently across industries. How would you define the essence of this role in today’s fast-evolving hardware ecosystem?

At its core, a Hardware TPM is the architect of execution velocity – the strategic orchestrator who transforms technical vision into market reality.

I define it across three key dimensions:

Technical Translation & Roadmap Planning: It requires system-level understanding to identify complex interdependencies that others overlook – the cascading dependencies between mechanical design decisions and firmware architecture, between supplier qualification timelines and regulatory submission windows, between component selection and manufacturing yield. The TPM creates roadmaps that not only define the path to completion but actively identify opportunities to realise value sooner. This means recognising which technical milestones unlock downstream parallelisation, which early investments in tooling or validation infrastructure accelerate time-to-market, and which architectural decisions create flexibility versus lock-in.

Execution: This is where strategy becomes measurable progress. It involves driving cross-functional areas – electrical, mechanical, firmware, software, supply chain, quality, regulatory –managing dependencies, and ensuring design, validation, and manufacturing advance in sync.

System-Level Leadership: Modern hardware programs span mechanical, electrical, firmware, software, supply chain, regulatory, and manufacturing domains. The TPM establishes the connective structure – defining ownership, decision flow, and integration rhythm so global teams function as one cohesive system. What's unique about today's hardware landscape is that complexity keeps increasing while time-to-market expectations keep decreasing.

What does it take to balance technical depth with leadership and cross-functional alignment in global programs?

The balance isn't about splitting time – it's knowing when systems level depth and when delegation accelerates execution. I use a three-level framework:

• Level 1: Systems-level engineering fluency. You must understand system, failure modes, cross functional system architectures/dependencies, supply chain, finance and manufacturing constraints deeply enough to ask questions. For example: when discussing 4-mil PCB traces that might cause 15% yield loss in production – this technical credibility prevents being misled by optimistic timelines.
• Level 2: Strategic Trade-Off Analysis. I engage deeply when decisions involve multi-dimensional trade-offs impacting schedule, cost, performance, or risk. When electrical engineering proposes a component reducing BOM cost by 8% but requiring three months of revalidation, this isn't purely technical – it's a program optimisation problem requiring simultaneous evaluation of financial impact, schedule risk, resource allocation, and opportunity.
• Level 3: Systematic Risk Identification and Dependency Management. For execution within established parameters, I create frameworks that enable distributed decision-making. This means establishing clear success criteria, defining decision rights and escalation thresholds, and implementing dependency tracking systems that provide early warning of cross-functional conflicts.

Hardware programs today involve global supply chains, cross-disciplinary engineering, and tight time-to-market pressures. What frameworks or practices have you found most effective to manage this complexity?

• Modified Agile for Hardware Development (MAHD): Traditional stage-gate is too slow; pure Agile is too flexible for hardware constraints. The most effective approach applies Agile principles to hardware realities. During architecture and early prototyping – when changes are cheap – we run true Agile sprints with two-week iterations using 3D printing and as one approach critical decisions – tooling commits, regulatory submissions, production ramps – one should transition to structured gates with rigorous technical reviews. Organisations using this approach show significant time-to-market reduction while maintaining quality metrics.
• Probabilistic Planning (Monte Carlo): Instead of single-point estimates, model program timelines with ranges. Feed live WBS with optimistic/likely/pessimistic task durations, variable lead times, and rework odds to get P50/P80 timelines, see which tasks drive most risk, and put buffers where they pay off.
• Early Supplier Integration: Bring suppliers and contract manufacturers into design phases so manufacturability, yield, and quality issues surface early when changes are cheap. Multi-tier visibility beyond Tier-1 to upstream dependencies helps avoid downstream surprises.

What do you believe separates a good hardware program manager from a great one?

• Execution vs. Value Creation: Good TPMs execute the plan. Great TPMs rewrite the plan to accelerate value delivery, optimising for time-to-revenue – recognising that markets don't care about internal milestones, only when customers can buy.
• Reactive vs. Proactive Risk Management: Good TPMs respond to problems as they arise. Great TPMs retire risks early through small investments in parallel paths – running multiple technical options in early phases, knowing that upfront cost saves months downstream.
• Process Compliance vs. Judgment Under Uncertainty: Good TPMs follow established processes. Great TPMs develop pattern recognition that distinguishes normal turbulence from signals requiring intervention. This judgment comes from cross-industry experience – knowing when to escalate, when to pivot, and when to hold course despite pressure.

Boundaries between hardware industries are blurring. What common trends do you see driving this convergence over the next decade?

• Silicon as Value Differentiator Across All Hardware: Compute capability has become the primary value driver regardless of product category. Vehicles now compete on semiconductor content and software capabilities rather than purely mechanical performance. This shift means hardware programs across all sectors now face similar challenges – managing supply chains, integrating complex firmware and software stacks, and balancing performance against power constraints.
• Electrification Creating Common Architectural Patterns: The transition to electric power systems is happening simultaneously across transportation, industrial equipment, consumer products, and infrastructure. This creates common design challenges around power management, thermal systems, battery integration, and safety architectures. TPMs who understand these common patterns can apply solutions across domains that traditionally operated in isolation.

What personal values or habits have helped you consistently deliver on ambitious hardware programs?

• Systems Optimisation Over Local Efficiency: Great programs optimise at the system level, not the component level. A decision that optimises one function often suboptimises the whole. Accepting slightly higher component cost might enable dramatic manufacturing simplification that reduces total cost and schedule. 
• Early Risk Retirement and Value Acceleration: In hardware, the cost of change increases exponentially over time. A design modification that costs $10K early in concept might cost $500K in production. This asymmetry drives a bias toward early action – making critical decisions and retiring major risks before they become expensive. 

For aspiring Technical Program Managers, what advice would you give to build credibility and effectiveness early in their careers?

• Develop Multi-Domain Technical Fluency: Build sufficient technical depth across electrical, mechanical, firmware, software, manufacturing, and supply chain domains to engage substantively with experts in each area.
• Master Dependency Mapping and Critical Path Analysis: Become expert at identifying dependencies that others miss – the cascading relationships.

Finally, what excites you most about the future of hardware – and where do you see the next wave of opportunity?

• AI and LLM Transformation of Hardware Organisations: AI and large language models will fundamentally reshape how hardware organisations operate. We're already seeing AI-assisted design tools that generate circuit layouts, optimise mechanical structures for weight and strength, and predict manufacturing yield from design parameters. Within five years, AI may likely automate significant portions of routine engineering work – generating test plans, analysing failure data, optimising supply chain decisions. For TPMs, this means our role evolves toward orchestrating human-AI collaboration. 
• Sustainable and Reusable Platform Strategies: The economics of hardware development are shifting toward platform thinking and reusability. For TPMs, platform strategy requires different optimisation. Instead of optimising a single product, we optimise a product family over multiple generations. Architectural decisions that cost more upfront but enable rapid derivatives create superior total value. 
• AI-Enhanced Risk Management and Probabilistic Scheduling: Advanced AI and simulation tools will transform how we manage program risk and schedule uncertainty. Instead of static Gantt charts with buffer built in arbitrarily, we'll run continuous Monte Carlo simulations updating probabilistically as actual progress data feeds back.

Krunal Patel is engaged in Technical Program Management/Business Analytics/Product Development/Mechanical Engineering.

Krunal Patel, a seasoned Technical Program Manager with deep expertise across semiconductors, automotive, and consumer electronics, shares strategic insights on leading complex hardware programs. In this conversation with Associate Editor Milton D’Silva, Krunal Patel shares insights on systems-level thinking, cross-functional orchestration, and proactive risk management as critical to accelerating value delivery in today’s fast-evolving hardware landscape.