At Very, we’ve been a remote-first organization from the beginning. Over time we have honed a remote culture that enables us to build software and hardware together without falling into time-killing traps. By empowering engineers, implementing Agile tactics, and defining clear responsibilities, we clear the way for our remote IoT engineering teams to thrive.
Stay Ahead of Remote Work Challenges
The need for remote work continues to rise as companies look to hire the best talent in a competitive hiring market. For years, remote workers were seen as early adopters, but now, with an increase in the hybrid work model, working remotely has transformed from a luxury into a necessity for companies that rely on top tech talent. While a remote workforce is a clear competitive advantage, there are also risks such as loss of visibility, accountability, and clear communication. Overcoming these challenges is hard enough with a software team, but how does it work with a hardware team building connected devices 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.
3 Key Process Strategies
As a consultancy, time is our most critical resource. Time is literally 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 costly to our business and clients. This is why our processes are heavily oriented toward saving time. The way we think about these processes can be broken down into three categories:
#1: Engineer Empowerment
Empowering engineers allows them to solve their problems without third-party bottlenecks or red tape. If engineers are forced to borrow tools from team members, some of whom might be as far as 1,000 miles away, you’re going to face unnecessary delays. To avoid this blocker, we start our engineering team members with a home lab stocked with the tools we consider to be standard for IoT engineering.
Another big time-saver in this domain is automatic cost approval for small purchases of tools, supplies, and shipping. The time an engineer spends waiting for some new specialty hardware or a refill on common supplies can paralyze a team, so each hardware and firmware engineer has a company credit card and is free to make any purchase up to $200 if they need it in order to deliver for a client.
In addition to automatic approval for small expenses, the hardware team maintains an active list of more expensive equipment that they can purchase without approval on an as-needed basis. For large orders that do require ad-hoc approval, we have processes in place that enable us to rapidly review and approve them with minimal red tape.
#2: Agile Processes
The Agile development method has existed for quite some time in the world of software, but the hardware engineering community has not adopted it as quickly. Despite its lack of prevalence, we’ve found the Agile methodology to be a very useful development process for our multidisciplinary IoT engineering teams (which include hardware engineering). We use Agile development at Very because it efficiently prioritizes our most valuable resource – time. For Very, the most important principles of Agile development are for IoT engineering:
- 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.
Agile principles are most evident in our hardware team’s approach to building prototypes. If following the traditional path of industry you start with a complete list of detailed product requirements, you then start a long period of “digital engineering” where designs are created and refined in computer-aided design (CAD) tools. This phase can last months and is typically punctuated with multiple design reviews, during which the entire team and other key stakeholders sit in a room and review the design files. Finally, after the project is almost complete, a prototype is built and tested. This method – also known as Waterfall – results in long design cycles and is fragile when faced with changing requirements or unexpected design issues found in the prototype.
Instead, at Very we focus our design cycles on building prototypes that deliver user value. This means that instead of starting with a detailed list of requirements, we start with a list describing the value we want to bring to the user. We use that list to come up with a plan for a prototype that will start to deliver some of that value. We rapidly move through the “digital design” portion of the cycle and build an initial prototype, often within a week or two of starting the project. Next, we test the prototype and start planning for the next one.
This cycle of rapid, continuous prototyping continues until we have a device that delivers the user the necessary value and is fully functional and tested in the real world. This is the minimum viable product (MVP). By following this method we can get to MVP faster, and with less risk, than traditional Waterfall development.
#3: Clear Responsibilities
By clearly defining responsibilities, we ensure 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 the hardware team, this is most clearly embodied in the role of the Integrations Engineer. Very’s Integrations Engineers are expected to straddle the line between electrical and mechanical engineering. They are the glue that holds a project together. The responsibilities include prototyping, giving design feedback, and helping guide the project toward manufacturing. This allows the electrical and mechanical engineers to focus on the design, and to get productive, real-world feedback on their designs from the prototyping process.
To allow team members to work most efficiently, the teams collaborate on the build test plans which clearly document the steps an engineer should take to set up and test a prototype. This prevents unnecessary interruptions of others’ work to answer questions about how to set up hardware for testing. In addition, we break down all tickets on our Agile planning boards into small chunks of work and assign each task to the responsible parties in our IoT engineering team. A clear definition of responsibilities ensures time is not wasted duplicating effort.
Even with our successful experience-based approach, we still find room for improvement, constantly refining our processes to remove blockers for our teams. By continuously improving our approach to remote work, we’ve shocked clients and peers with the speed and value that we deliver using a fully remote IoT engineering team.