Note: The opinions voiced in this retrospective are Jon’s. Other Technical Machine team members may or may not share the same thoughts.
The Low Point
We had some legitimate problems: when we shipped we had nearly a third of customers contact us with fulfillment issues, we missed a critical GPS module hardware issue, and most of our software testing infrastructure was decrepit when we shipped rushed code, to name a few. But those issues aren’t difficult to solve. Those issues have been more or less fixed with a combination of engineering time and money.
But we had a scarier issue: our motivation to keep pushing was dwindling. Before shipping, we had this single, unifying, direction-full goal of getting this novel product out the door. But after Tessel was in the hands of users, all there was to do was feel burnt out from the 16 hours days, fix those difficult bugs that had been haunting us (and now our customers) for months, and try to track down lost shipments. Sure, there was the joy of hearing from our customers how much they loved our getting started experience but, between those snippets, it was hard to not feel demoralized. Surely, there had to be more to it than this?
During my one-on-one meetings with everyone on the team, they each independently explained that they felt that we were now directionless. Why wasn’t I providing more direction for the company? “We need to be working on the next thing by now”, they all said. What was the grand vision for Technical Machine?
The truth was, I didn’t have one yet. I felt that this was our time to learn as much as we could from our product being released into the wild. I thought that the future of our company depended on what our customers taught us about how they build hardware with Tessel.
It turns out, as is usually the case, I was partially right and mostly wrong.
Myself excluded, the entire team consisted of “research-heavy” engineers. Engineers who want to build entirely new things as quickly as possible and aren’t as interested in polish. Nobody on our team strongly identified as the type of engineer who likes to sit down and make a code base shine. The desire to fix bugs and maintain the product after it was released was not as high as developing a prototype to begin with.
To compound the problem, we had little testing infrastructure in place while developing Tessel, so our product was buggier than it could have been (an artifact of having just graduated from college, where testing code was rarely discussed or practiced).
In short, there were more bugs to fix and nobody interested in fixing them. Asking our engineers to continue preening over our existing code base after months of working on it wasn’t making anyone happy or productive.
At this point, we had two related but distinct issues: the company had little sense of direction, and what we did have to work on wasn’t making anyone excited to come in to work.
In an effort to give our company more direction, we started having long brainstorming sessions about what we wanted to build and where we wanted the company to go. We talked about what we had learned from customers using Tessel in the wild. We talked about what we were interested in as individuals.
Ultimately, we arrived at a couple of key points:
- Prototyping tools and manufacturing tools have traditionally been disjointed. There has always been a leap from the device that proves out the viability of an idea and the device that eventually gets to market. Creating a sustainable funnel for customers to progress from prototype to a product at scale is a business opportunity worth pursuing.
- As a company, we’d like to head further away from the toy/hobbyist market and closer to being a trusted provider of embedded hardware tools – not just for web developers but eventually electrical engineers and seasoned product developers as well.
- We’re not interested in being another hardware platform that succumbs to building the “IoT cloud” to rule them all. We feel that, while cloud platforms have their intricacies, the technical and social engineering challenges are not appealing.
- Tessel’s getting started experience is top-notch. Integrating npm with the hardware modules provides for (in our opinion) the fastest prototyping platform available. Users could go from unboxing with no hardware experience to serving pictures from the camera module in a web app in under 5 minutes. It’s important to us to continue enabling that type of interaction.
Focusing our attention on Scalability
Based on what we’ve heard from users of Tessel, one of the most important and opaque transition points from the “idea viability” stage to the “technical prototype” stage is picking out the actual components (integrated circuits, sensors, etc.) that are to be used in the final design.
We held quite a few brainstorming sessions as a whole team but didn’t make much progress until Kevin, Eric, and I were casually discussing the hardware development process.
Kevin, our lead firmware engineer and previously a co-founder of a hardware tools company called Nonolith Labs, started explaining an idea he had for how hardware development should be done. I’m not sure how much of it was formed before our brainstorming meeting, but it came out in a fairly cohesive stream. Kevin’s idea was largely focused on software defining hardware interfaces in such a way that it becomes possible to automatically generate more components of a hardware device.
Imagine embedded hardware development as being composed of six levels of abstraction:
Data Flow: A description of how data flows between different inputs (sensors) and output (network) blocks, as well as code blocks (JS, Rust, C, etc.) of various languages.
Firmware: A verbose and precise description of machine-readable code that dictates how the hardware works at the lowest level to allow that flow of information. Boilerplate configuration code, for example, setting up registers to communicate with external memory, can be autogenerated if parts are known.
Part Selection: The actual integrated sensors and integrated circuits that comprise the system. There is a dependency between the code that is generated and the microcontroller that is used.
Schematic: How the pins should be connected together. If parts are known, then this becomes an datasheet scraping problem.
PCB: How components are physically laid out on a circuit board. If a schematic is known and context of each signal is known (is this power, ground, a high speed usb signal, RF signal, etc.), then a PCB becomes easier to automatically route. Auto routing has traditionally been considered a bad practice and nobody has done it well yet.
Manufacturing: Who actually manufactures the PCB and/or assembles the parts.
In theory, the hardware development process could be described from any of the above levels of abstraction (besides manufacturing) and a circuit board could be generated as precisely as it was described. Each level of the process should be optimizable so that a seasoned firmware engineer could tweak the firmware or an electrical engineer could add necessary passive components and modify the size of any sensitive traces.
The idea of “software defined hardware” resonated with the team as a solution space worth attacking. An accessible but powerful hardware development tool that would take years of development work aligned very well with the personal interests of everyone on the team. The question turned from “what are we building next?” to “how do we approach such a giant, complicated system?” Once we we were able to frame the problem around solid technology choices that could accomplish the goal of “software defined hardware”.
Tessel is just the first development board which would be the target of this new hardware development tool. Over time, we hope more and more microcontroller targets will be contributed so that our open source tool can extend past just the Tessel ecosystem. We’ll be releasing more information about this new tool as we start speccing it out.
As for maintaining Tessel’s architecture, we’ve made a huge amount of progress. By having each person in the company split their time between working towards these new engineering goals and working on maintaining the released Tessel platform, we’ve reinvigorated our collective enthusiasm for our vision. We’ve also started hiring people who would be well-suited for support positions. In that vein, we’ve hired Ken, who is one of the most patient and detail-oriented people I know, to work on improving Tessel’s JS and Node compatibility. We’ve also hired an external contractor to work on some of the finer points of JS compatibility like the unicode implementation.
We’re really excited about our new direction but we still have a few questions to answer:
- Who are our customers? Tessel’s customers are usually web developers interested in hardware. But now that we’re starting to prototype tools for the wider user group of product developers, how do we market our product and who do we approach about user research? We also need to gather more information about how much of our current customer base is interested building scalable devices and how many are building one-off solutions.
- Is this user group big enough and growing fast enough to be sustainable? Tessel itself hasn’t yet answered the question of how big the group of hardware-interested web-developers really is and it’s unlikely that traditional product developers will use our system until it’s more proven.
- How do we go about automating the “human” parts of hardware development? The deals with manufacturers and working with suppliers, smoothing out issues with contract manufacturers, and debugging issues with field application engineers all currently require face to face interactions.
We’ve still got a lot of work to do before we start making the hardware development experience we’ve been dreaming up. In the past year we’ve learned a ton about what it means to build a company but we need to start talking to users to get these new questions answered. If you have experience or suggestions you’d like to share, please email me at email@example.com. I’d love to hear it.
We also have open, full-time positions that we’re hiring for, including web developers, HR/recruiting, business development, and firmware engineers. If you’d like to contribute to our vision of reimagining hardware development, don’t hesitate to reach out!