As costs are rising in typical tech Meccas, remote work is being touted as a competitive advantage for early adopters. In recent years, many companies have been adopting this model, and some label it as a key reason for their success.
While there are clear advantages of having a remote workforce, there are also many risks. These include loss of visibility, accountability, and clear communication. Getting these things right is hard enough with a software team, but how does it work with a hardware team in an industry that touts the adage "hardware is hard"?
At Very, we’ve built a remote culture that tackles the main concerns around distributed work, which puts us ahead of the curve when it comes to building a distributed hardware team. Building on this foundation, we have implemented several additional policies and procedures that enable us to be successful.
At the core of our process is the mutual understanding that as a consultancy, time is our most critical resource. Time literally is money to us and our clients. If a hardware engineer is blocked, or if the software team is blocked by the hardware team, it is very costly to our business. This means that all of our processes are oriented toward saving time above all else. The way we think about these processes can be broken down into three categories, "Engineering Empowerment," "Agile Processes," and "Clear Responsibilities."
Empowering engineers is critical because it allows them to solve their own problems without involving many third parties (and red tape). One of the biggest time-savers in this domain is automatic cost approval for purchasing of tools, supplies, and shipping. Each hardware and firmware engineer has a company credit card, and is free to make any purchase up to $250 if they need it in order to deliver for a client.
The time an engineer spends waiting for some new specialty hardware or a refill on common supplies can often paralyze a team, which is why we operate with this policy. In addition to automatic approval for "small" expenses, the hardware team maintains an active list of more expensive equipment that can be purchased without approval as-needed. In a distributed setting, it's critical that team members have their own tools within arm's reach because the closest team member who could lend a tool may be 1,000 miles away.
The Agile development method has existed for quite some time in the world of software, but it has not been adopted quickly within the domain of hardware engineering. Despite its lack of prevalence in the hardware engineering community, we've found it to be a very useful development process for our multi-disciplinary IoT engineering teams (which include hardware engineering). At its core, Agile development is just a means for ensuring that time is used in the most efficient manner, which is why we use it at Very.
The most important principles of Agile development as interpreted by Very are:
- Continuously deliver value to end-users.
- Ensure features are production-ready before moving to new features.
- Test early and often.
- Make a decision at the last responsible moment, and not before.
The biggest manifestation of these principles in our hardware team is the approach to our PCB design. The traditional path of industry involves scrutinizingly selecting a full BOM first, then work out the schematic, then perform the PCB layout, then prepare manufacturing instructions and order prototype boards. This results in long design cycles and is fragile when faced with changing requirements. Instead, we move through the full design cycle component by component.
This means we first select a processor, and its minimal required peripherals, work out the schematic for this small number of components, then lay them out on the PCB and create manufacturing documentation. This often means that after a couple of weeks, we could receive an order of production-ready (but not feature complete) PCBs.
We then step through each new component of the design in the same manner. This method yields schematics and layouts that are more modular and robust to change and prevents time loss by making pre-mature decisions (i.e. scrutinizing over a BOM for weeks only to have requirements change later, making much of it obsolete).
Lastly, clear definitions of responsibilities are critical to ensuring that team members know what work belongs on their plate and who to go to when they identify work that doesn't belong to them. For our hardware team, this is most notably useful in distinguishing Quality Assurance (QA) work from engineering work. QA is a crucial part of our IoT engineering strategy, but when QA gets its hands on early prototypes, the lines between QA, hardware engineering, and software engineering can blur.
In order to allow team members to be utilized in the most efficient manner, the teams have collaborated to build QA test plans which clearly document the steps QA should take before they reach out to engineers. In addition to this, all tickets on our Agile planning boards are broken down into small chunks of work and are labeled with the responsible parties. This ensures everyone understands who will be accomplishing a given task.
We still see room for improvement and are constantly refining our processes, but over this time frame, we've shocked clients and peers with the speed and overall cost of development that we are able to deliver.