Building the Team

To design a great product, you must start by designing a great team. I've shipped four products from prototype to production, seen over 100 NPIs, and interviewed hundreds of leaders. Those experiences taught me some important lessons about building high-functioning hardware teams. Whether inside a large company or as part of a startup, building a new hardware team is about more than just adding hardware engineers -- you’ll need software, manufacturing, and operations as well.

How big should the team be?

I’ve seen successful hardware teams as small as five to as large as 60 -- and even some teams into the hundreds. The general calculus is that the bigger the size, the more difficult it may be to pull together (or hire) the resources you need. Large teams are not as nimble as small ones. On the flip side, while smaller teams can change directions quickly, they may be stretched too thin to push on all necessary areas in parallel. So what is the “right size?” The most important principle is that team size should correlate to product confidence. Before having full product confidence -- proof from the market that the product will be viable -- you should fill your team with just enough to cover the core technology of your product in-house. Avoiding premature team expansion will save you money and buy you more time to build confidence. Where startups will have natural time and budget constraints, larger companies will have constraints determined by the financial and business risk management is willing to take to bring the product to market. The smallest successful team we’ve seen get a product shipped that met their customers’ needs and succeeded in the market is five. The product included relatively simple hardware and a mobile application. A more comfortable size I’ve seen work well is starting at around 15 or so and then growing to approximately 25 as the product approaches readiness. The big electronics companies will often have hundreds of people working on a program -- but I don't believe that necessarily makes that product go faster. The original iPod teams were small, with less than 100 people across Apple, including software and other functions -- products shipped from prototype to production in approximately nine months, and builds lasted four days. When I left Apple in 2015, iPhone and Watch teams were hundreds strong, products took twice as long from proto to production, and builds lastest weeks or months. More people do not mean faster results.

You can also get creative and keep a team small by augmenting it with Joint Development Manufacturing (JDM) resourcing from a factory partner.

Who should be on the team?

The key to keeping your small team effective is to stack the deck in your favor by filling it with people with experience in exactly what you need to do. Prior experience in the type of production environment you have (high-volume, regulated, zero-defect requirements, etc) and first-hand engineering/operational know-how will go a long way toward doing more with less. In the case of the five-person team, every single member had significant prior experience, making the super lean team possible. As another example, Rylo had only a single product design engineer. This engineer has previously been through multiple high-volume, high-quality programs at a large company. He was able to design and deliver the mechanical and manufacturing design for an entirely new product on his own, with resulting product quality rivaling that of the biggest brands (who might have assigned five or more product design engineers to develop a similar product).

What are the roles on a hardware team?

A hardware team has four broad disciplines: design, technology, operations, and software. Big teams can use many people to cover all the roles within these disciplines. Here’s an example of some of the individual hardware-related roles you might find on a big team:

1. Design:
   1. Mechanical Engineer
   2. Industrial Designer
   3. FEA Engineer
   4. Materials Engineer
   5. Engineering Program Manager
   6. Reliability Test Engineer
2. Technology:
   1. Electrical Engineer
   2. Antenna/Bluetooth Engineer
   3. Camera Engineer
   4. Display Engineer
   5. Battery Engineer
   6. And more...
3. Operations:
   1. Test Station Designer
   2. Manufacturing Engineer
   3. Operations Program Manager
   4. Tooling Engineer
   5. Quality Engineer
   6. Supply Chain Manager
   7. Procurement
4. Software:
   1. Firmware Engineer
   2. Hardware Test Engineer
   3. Software Engineer
   4. Web Developer
   5. And more...

Small teams have to cover these roles with far fewer people. This means that for most new teams, there will have to be a decision on which roles to cover in-house and which ones to outsource.

What can I outsource?

First, ensure you cover roles related to your core technology in-house. Ultimately, your requirements will be unique. There are a few general guidelines that typically ring true (though we’ve seen exceptions):

1. I’m biased, but you usually don’t want to outsource the mechanical design . You want at least one person overseeing mechanical engineering and product design on your team -- or at least systems engineering (a kind of electro-mechanical generalist who can own a JDM program). They will own your product's overall function, reliability, fit, and finish -- and likely the physical parts that make up your core technology. They will be empowered to fix issues, and they will be incentivized to do so to prevent long and grueling trips to your factories overseas. This person is often versatile and can fill in for a broad range of expertise, including some operations roles, and lean on vendors when needed.
2. You usually don’t want to outsource roles related to factory relationship management . This person will own the relationships between your company and its vendors, which are critical for program success. Better relationships can sometimes mean better quality, price, or service with a vendor. This team member will also own the schedule for getting your product out on time, essential for hitting your sales goals.

So what can you outsource? Specialized roles unrelated to your core technology are a good place to start. Some examples of roles that can typically (but not always) be outsourced are:

1. Industrial design . Even if product design is part of the core technology, most of the contribution from the industrial designer is compartmentalized and upfront. Moreover, continued industrial design “meddling” can reduce the efficiency of your mechanical engineers (this one comes from experience).
2. Siloed technology engineering roles . These roles, such as battery engineers, display engineers, or camera engineers, are often too specialized to provide ongoing value throughout the entire development process. Even for electrical engineering, it’s sometimes the case that your electrical design is simple enough that you don’t need a dedicated full-time person and can instead rely on another engineer on your team with sufficient EE experience, contract a resource for a short-term engagement, or leverage a JDM partner. If you’re building an innovative camera product, you may need a camera engineer in-house -- but maybe not a battery engineer if you can source off-the-shelf parts.

Again, these are not hard and fast rules. We know of one successful hardware company that realized their core technology was truly only software -- so they built their tiger team to reflect that, concentrating staffing decisions to focus on software application design, UX, and UI. They built only a minimal in-house team for the actual manufacturing and managed to outsource their mechanical engineering.