.png)
Introducing our newest series! In the company talk series, we will interview awesome people at hardware companies, from startups to public companies. We will post a new one each week. Enjoy!
In this week's series, we spoke to Andrés Cassinelli, an EE manager from eero. eero was founded in 2014 in San Francisco and is known for its home WiFi systems. Most recently, they released the eero 6, which can cover up to a 5,000 square foot home. We talked to Andrés about his journey to eero, eero being acquired, and how his team's processes have changed due to the pandemic.
I'm an electrical engineer by background and prior to eero I worked at a consumer electronics startup called Ooma and a large semiconductor company called Altera (acquired by Intel), where I built boards for “first silicon” bring-up and testing of new chip designs.
I really like the dynamic nature of a smaller company and the ability to deliver a product that you, your family, and your friends might end up using as opposed to hardware infrastructure that is cutting edge, complex, and challenging to design, but meant only for internal use.
When I joined eero we had fewer than 15 employees. I was the second hardware engineer, and the first one focused on system-level integration. There was very little process and infrastructure set up, especially on the hardware side of things.
At an early stage, it's relatively easy to implement processes that are deliberately designed, but there is also a strong pull towards letting processes emerge on their own based on whatever is the highest priority at any given time. Since we had the opportunity to start from a blank slate and set ourselves up for success at a larger scale, I consistently advocated for the “deliberate design” approach. I think we were able to follow it fairly successfully given the day-to-day challenges of a startup.
As you grow, a "this is how we've always done it" mindset becomes more common, whether or not there is a good reason for it. The more you go on with that mentality, and the more people get used to that, the harder it is to change existing processes. Larger companies also have more stakeholders with different backgrounds and opinions, which have to be considered and managed as part of any effort to implement, change, or eliminate processes. While we now have these additional constraints, starting from a solid set of processes created in the early days has helped to reduce their impact.
When we were acquired we thought we might be required to do everything the way our new parent company did it. Fortunately, that wasn’t the case. The biggest actual change has been the ability to shift towards more long-term thinking. As an independent company, you're never really sure what's going to happen 1, 2, or 3 years out. In “startup mode” you need to do whatever it takes to get through the next month or the next six months, and sometimes that can lead to decisions that are not optimal over longer periods of time.
At an early stage, it's relatively easy to implement processes that are deliberately designed, but there is also a strong pull towards letting processes emerge on their own based on whatever is the highest priority at any given time.
We started working on the hardware design in late 2019. It was one of the first times we used the joint development manufacturer (JDM) model, as opposed to a contract manufacturer (CM) model. We had to do this while dealing with the unpredictable effects of a global pandemic, so we were learning on many fronts simultaneously.
During our first few programs, we did all the design work internally and then went to a partner just for manufacturing. With the change to a JDM model, we started working very closely with partners in Asia from the prototype stage, trying to leverage their R&D resources to accomplish more in a shorter period of time. I led the hardware engineering team for the the eero 5 program, which was our first true JDM experience and happened towards the end of eero’s time as an independent company. It was an interesting challenge with lots of rocky moments, and we learned a lot from it.
For the eero 6 program, we partnered with the same JDM and were able to work together a lot in person in Asia right before the lockdowns started. The architecture and prototyping for eero 6 happened right before the pandemic hit, and that was extremely helpful in terms of pulling us through building remotely afterwards. With a good foundation of shared experiences with our partner, we were able to do a really good job with the design in this JDM model even though we no longer had the option of collaborating in person. We were constantly trying to figure out how to keep design and collaboration going across time zones. Somehow, we made it work!
Design reviews have always been a bit of a struggle. They happen in a continuous and ongoing fashion. Since we are still a fairly lean team and our program schedules are often aggressive, we don’t really have the ability to hold weekly or monthly design reviews where we pause and go through everything that’s been changing in a design.
Before the pandemic, there was a lot of sitting together, looking at different parts of a design, and working together when we traveled. We’d go through Excel action trackers at least twice a week in the evenings, with additional ad hoc meetings when necessary. For each NPI build, we would gather people in a room and have a “here’s your last chance to say something” meeting before we released the design to manufacturing.
During the pandemic, we would still review outstanding issues at a similar cadence using similar trackers, but we discussed them live over Zoom instead. With fully-remote meetings, we've gotten better at compiling design review feedback and tracking changes related to it. We started using Google Slides for this, both because it’s easy to collaborate on it across sites and time zones, and because it can present lots of visual information more efficiently than other tools. We also became more diligent about uploading all design files to a single location ahead of time and trying to get stakeholders to provide feedback well before a release deadline. That's definitely something we'll aim to keep doing in the future.
With a good foundation of shared experiences with our partner, we were able to do a really good job with the design in this JDM model even though we no longer had the option of collaborating in person.
I think that in-person collaboration is still fundamentally more efficient than remote work for hardware development. However, it is too often used as a crutch to avoid setting up good processes for work that isn’t hindered by the lower efficiency of remote collaboration. Having good tools and systems of record for these kinds of work is something that adds a lot of value to a company.
It's about helping hardware engineers be better prepared for meetings (to keep them efficient and focused only on what has to be done in a group setting) and also tracking action items and associated design changes post-meeting.
Hardware-focused software tools would be a huge improvement because instead of spending part of every meeting catching everyone up on the latest state of a design, they would enable designers to focus on concerns that reviewers have already pointed out and make sure they get the group’s input on all of them.
There’s a lot of value in having as many eyes as possible on a design that is still evolving, but today that requires a lot of effort and/or large teams. Being able to easily highlight potential design issues and compile questions without having everyone in a room at the same time would make those benefits much more accessible to a wider range of organizations.
JIRA is the standard for issue-tracking within our company. It's got a lot of pull because it’s used cross-functionally by manufacturing, software, etc. The problem with JIRA is that it has a lot of overhead and it is usually for things that are not helpful for hardware development. JIRA is very much designed and optimized for software development.
A lot of other teams want to track information exclusively in JIRA, but we’ve been trying lighter-weight issue-tracking tools like Asana to see if they show a better ROI for hardware development. Getting people to use multiple systems simultaneously is tough though, especially if they’re not well-integrated. It's much easier if you can have a single tool that aggregates everything in one place.
Hardware-focused software tools would be a huge improvement because instead of spending part of every meeting catching everyone up on the latest state of a design, they would enable designers to focus on concerns that reviewers have already pointed out and make sure they get the group’s input on all of them.
The JIRA user interface is also a mess. They keep releasing new versions, and each one makes it harder to find what you’re looking for than the one before it. There’s just too much space devoted to fields that are not applicable, and there’s no easy way to remove them to free up space for what matters. I'm hoping that new, better tools can surface only the necessary information and make the irrelevant stuff fall away more easily.
My advice is to try to organize information about what is changing in a design, why it’s changing, and what problems are being solved with each change. The data behind that is really helpful in order to avoid making costly, unnecessary mistakes and wasting precious time fixing them later.
It’s hard to set aside time for that when there are so many other competing priorities. It feels like you move faster when you don’t do that, but you’ll eventually hit issues that could have been avoided and may end up spending more time addressing them than it would have taken to prevent them from happening in the first place.
My advice is to try to organize information about what is changing in a design, why it’s changing, and what problems are being solved with each change.
So in summary, be wary of moving too fast and try to find a sweet spot between getting stuff done and understanding the risks and expected outcomes of your actions. Don’t get too bogged down in process, but know that if you’re always sprinting you’ll probably be overlooking important things along the way. This is based on mistakes I’ve made and witnessed, and hard-earned lessons I’ve learned at eero and elsewhere.
We want to thank Andrés again for taking time to chat with us. We hope you enjoyed this post and stay tuned for the next one! :) If you're interested to learn more about Bild, please don’t hesitate to reach out to us at contact@getbild.com!