Bringing Startup Speed to Enterprise Electronics Design

Key Takeaways

• Growing hardware teams rarely slow down because of schematics or routing. They slow down waiting for reviews, chasing unclear next steps, and getting expert input too late. Improving that communication takes modern, asynchronous tools.
• Hardware can't directly copy software's approach to review, because boards need to be built and tested, and many industries follow their own development processes, such as EVT/DVT/PVT validation stages in consumer electronics, APQP (Advanced Product Quality Planning) in automotive, and ISO 13485 design controls for medical devices.
• Altium Agile Teams lets administrators build their own process as a workflow, with forms, assigned reviews and approvals, lifecycle state changes, and publishing to product lifecycle management (PLM) systems. These workflows can help large teams stay as fast and nimble as much smaller ones.

Think First, Then Run Like Hell

ŌURA turned a handful of sensors, a tiny battery, and a titanium shell into a multi-billion-dollar business. The Oura Ring, now in its fifth generation, tracks biological metrics such as sleep, heart rate, and activity, then sends the data over BLE (Bluetooth Low Energy) to an app on your phone. In October 2025, a funding round of more than $900 million valued the company at about $11 billion, bringing its total funding to roughly $1.5 billion.

Engineers, entrepreneurs, and product designers alike look at companies like ŌURA with more than a little envy. Can our product be the next big thing? Can our organization be as successful? And can we keep that pace in fast-growing, highly regulated industries?

On the podcast Masters of Scale, ŌURA's CEO Tom Hale summed up how the company works:

"You take a moment to think about what you want to do, but once you know, you run like hell."

However, anyone who has worked in a large company knows that, no matter how clear-headed and ambitious its direction, the speed of progress depends on coordination between teams and lean, effective processes that keep the work moving forward.

Team Growth and Decision Speed

Go ahead: turn to the fellow hardware engineer next to you, or message your colleagues on Teams, and ask: "Where do you think we're wasting time? What part of our design process is slowing us down?"

Chances are, the complaints will have less to do with the time spent drawing schematics and routing PCBs than with the scheduling and management of the work itself. They might sound something like this:

• "I'm waiting for someone to look at my design." The engineering work itself is ready, but the person who can answer specific questions, review the design, or approve the change is busy elsewhere (or appears to be).
• "I'm not really sure what I'm supposed to do." Information about next steps and outstanding tasks is fragmented and confusing, so it's hard to keep track of what needs doing across several ongoing projects.
• "Why are we finding this out now?" While our heroic engineer has been hard at work on the design, colleagues with critical expertise elsewhere in the team or company haven't had a chance to meaningfully contribute. Their input will likely arrive too late, slowing and frustrating everyone involved.

On the surface, a team's output should scale linearly with the number of contributors. Twice as many engineers should lead to twice the amount of work completed. But if everyone needs to coordinate with everyone else, a team of n people will have n(n-1)/2 pairwise connections, as Frederick P. Brooks Jr. showed in chapter 2 of The Mythical Man-Month: Essays on Software Engineering (Addison-Wesley, 1995). Five people have ten possible connections; ten people have forty-five. Double the headcount, and the number of possible connections more than quadruples, following a quadratic trend.

And of course, if every one of those connections could block work, filling our to-do lists with statuses such as waiting for review, blocked until clarified, and rework needed due to missed requirements, we would never be able to complete any work. When designing PCBs, even minor issues, such as colleagues not having an ECAD licence, or a senior engineer reviewing out-of-date PDF printouts, can add up and slow projects down far more than necessary.

Lessons From the Software Giants

Software teams were not the first to run into this problem. However, software teams had one distinct advantage: they could not only come up with efficient processes, but also build the tools to implement them, using the same skillset.

Code review is a good example. The larger and more complex a project and the more developers involved in it, the more code reviews it needs. Yet despite the staggering amount of code written over the years, code review has scaled remarkably well.

Google, which between 2014 and 2016 had more than 25,000 developers in dozens of offices making more than 20,000 changes each workday, requires every change to be reviewed before it is committed. When Caitlin Sadowski and colleagues studied the process, they found developers waited a median of under an hour for initial feedback on small changes, and the median review, of any size, took under four hours.

Even over a decade ago, those reviews happened largely without meetings, Teams calls, and to-do lists made on Post-its stuck on whiteboards. Instead, the author submits a change, and an automated tool suggests reviewers based on code ownership, coding language skills, or team-based rules. Each reviewer comments on the precise lines that concern them, often directly in a web-based review tool. In the paper's words, the cycle "continues until everybody is satisfied or the patch is discarded."

The lesson growing hardware teams can take from software is not to review less, particularly now in the face of work done in collaboration with AI agents prone to hallucinations. No, the lesson is that when the reviewing process is tightly knit, asynchronous, and iterative, it can run at the speed demanded by even the most talented and demanding engineers, with no need to wait on a weekly meeting.

Altium Agile Teams allows large teams to collaborate, comment, and review directly on the design. Engineers can leave comments on any schematic or PCB object, tagging colleagues with an @mention so the question reaches them with the appropriate context. Any comment can then be turned into a task assigned to a colleague, and anyone, from a fellow EE to a mechanical engineer to the purchasing team, can follow along in a web browser without needing a separate ECAD licence.

Periodic vs. Design-Based Reviews

Hardware Development Process

Unfortunately, the hardware industry cannot copy software's review habits wholesale. While a software test suite may run in minutes on a large VM in CI, even simple tests can take an entire afternoon on a hardware design: configuring instruments, reworking components under the microscope, and holding 3 probes steady on tiny test pads while shouting at your colleague to hit the Single button on the scope. Unlike software, which is ephemeral by nature, a PCB cannot be fully evaluated until it has been fabricated, assembled, and brought up.

Because each build is slow and costly to change, the hardware industry has converged on a handful of standard development processes:

• EVT, DVT, and PVT, the engineering, design, and production validation stages used across much of consumer electronics: does it work, does it meet its requirements with production-intent parts and tooling, and can the factory build it at volume?
• Stage-Gate, formalized by Robert G. Cooper, which splits the journey from idea to launch into stages, each ending in a go/kill decision.
• APQP and PPAP (Production Part Approval Process), widely used in automotive, consisting of five phases from planning to post-launch corrective actions.
• Medical device design controls, now part of the FDA's Quality Management System Regulation, which since 2 February 2026 has incorporated ISO 13485:2016.

They share the same elements: defined stages, a review at each boundary, careful revision records, and change control that tightens as the product matures and changes become more expensive. Any solution for collaboration, review, and project management must support the flexibility required by the different development processes.

Adapt Your Tools to Your Workflow

So how does Altium Agile Teams fit into these development processes? Rather than replacing them, Agile Teams allows the engineering team and IT administrators to define workflows matching whatever industry you're in. Workflows are built in the Process Workflow Editor, where administrators can draw each step as a diagram using familiar tools.

For project activities, such as design reviews and publishing to PLM, a step can:

• Collect information through a custom form.
• Assign a task, review, or approval to specific people or a group.
• Send a notification to a user.
• Change lifecycle states.
• Collect project data for the process.
• Publish released project data to a connected PLM system.

The workflow can also branch according to a decision or result, wait for a PLM operation to finish, or require all related tasks to be resolved before completion.

Thankfully, nobody has to start from scratch. Altium supplies several standard workflows, such as:

• Ad-Hoc Review: Gather feedback without a formal pass/fail conclusion.
• Handoff Review: Decide whether the design can move to the next stage.
• Milestone Review: Repeat work and verification until the design is approved or rejected.
• Project Releaser with Publish: Add PLM publishing to the release process.
• Publish to PLM (User selects): Choose which released outputs to send to the PLM.

Additionally, part requests use the same workflow and form editors to manage requests for new library components, ensuring a consistent experience for engineers and librarians alike, while enforcing lifecycle policies. Parts and released designs can move through easy-to-understand lifecycle states such as Prototype and Production, and at release the Project Releaser can run ERC, DRC, and component state checks, refusing to release a board that includes unreleased components.

And if you manage released data in a PLM, Agile Teams links to Duro and Arena. Duro also provides AI-assisted change impact analysis. This helps reviewers predict how a proposed change could affect components, assemblies, schedules, and designs before sign-off.

Workflows take care of the bureaucracy for you. Instead of engineers filling in forms after the fact, updating to-do lists after a meeting, or assembling records for an audit, every request, review, and approval is captured automatically in the workspace as the work is performed.

Agile Teams doesn't define your development process or make you ISO 13485 compliant on its own. It runs and records the process your team defines.

Startup Speed, Enterprise Discipline

Growing a hardware team shouldn't mean giving up the speed and flexibility of a startup. Yet as a team grows, the same complaints start to appear: designs waiting on review meetings, unclear next steps, and expert input that arrives far too late. And in highly regulated industries, such as automotive, aerospace and defence, or medical devices under ISO 13485 design controls, sloppy work is not an option.

Altium Agile Teams is built to combine enterprise scale with startup flexibility, letting engineers, mechanical designers, and other team members collaborate, comment, and review the design, while easy-to-configure workflows keep the process smooth.

Learn more about Altium Agile Teams →

Frequently Asked Questions

Why do hardware engineering teams slow down as they grow?

It isn't the design work but primarily coordination: engineers wait for reviews, chase unclear next steps, and get expert input too late. The number of connections between team members scales quadratically, so coordination is paramount.

What is the best way to reduce engineering review meetings?

Review designs asynchronously. Altium Agile Teams lets engineers comment directly on schematic and PCB objects, @mention colleagues, and turn comments into tasks, without waiting for the next meeting.

Why can't hardware teams use the same code review process as software teams?

Because a PCB is a physical object that can't be fully evaluated until it has been fabricated, assembled, and brought up, so hardware teams group the work into a few stages, with a review gate between each.

Can Altium Agile Teams enforce review and release workflows that match our development stages?

Yes. Administrators draw their own processes in the Process Workflow Editor and use them for both projects and parts.