The Linker is a new blog from Christopher White and Elecia White, hosts and creators of the weekly embedded.fm podcast. The Linker discusses embedded software and hardware engineering, education, and entrepreneurship. The goal is to dive deeper into the tangential topics brought up during the show.
On Embedded.fm episode 90, guest Tod Kurt of ThingM (“thing-um”) took us on an exploration of that most critical piece of all embedded systems: the blinking light.
Tod co-founded ThingM in 2006, making I2C-programmable LEDs. Their first product, the BlinkM, is a small embedded system in its own right, with an ATtiny MCU, supporting hardware, and an RGB LED. The exposed-circuit devices can be controlled from another microcontroller or pre-programmed with a pattern that will be shown when powered independently (5V). Since their first product, ThingM has expanded the line into small (MinM) and large versions (MaxM).
Their newest device, the Blink(1), is a departure from this path. Utilizing a USB-for-tiny-devices PIC processor (PIC16F1455-I/ML), the Blink(1) is controlled from the USB port of a computer (or server blade!). With support built into the Linux kernel (and drivers for Window and OSX), the light can indicate anything the web has to offer. Like its predecessors, the Blink(1) can also be programmed with a script to be run off any USB power source.
The older BlinkM I2C devices have found their way into numerous applications: hobbyists, practical effects for films, industrial machine status display, etc. The odd part is that, according to Tod, “for the longest time we really didn’t know what people were using them for” [1:54].
Engineers are often motivated by a desire to solve a particular problem for a particular audience. Sometimes, our imaginations are limited by the practical necessity of having a focused vision. When the devices get released into the wild, their intended use may be altered by its consumers. Tod was upfront that he didn't originally set out to make I2C LED circuit boards. He and his co-founder were planning to make their own interesting designs and then release them to the mass consumer market. Tod said that they “accidentally fell into the maker/Arduino market” [5:54].
Being open to marketing the BlinkM to a different community than initially planned (makers vs. retail customers) was as an experiment. It led ThingM to new customers and new product ideas. Awareness and acknowledgment of the things you don’t know can be just as important as a clever idea and flawless technical execution.
After years of selling BlinkMs and variants to hardware enthusiasts, ThingM made a conscious decision to return to the original plan and go after the retail market with the Blink(1). Tod: “Blink(1) was us wanting to explore the retail side. Instead of exploring a cool engineering project, it is exploring cool business problems” [33:40].
That statement struck me as a really interesting angle on product development. So often engineering-driven companies solve hard problems within the technical disciplines they understand. Companies are driven to make the software or hardware faster, smaller, cheaper, and more feature-rich. Failure sometimes hides in other fields that we engineers discount like marketing, industrial design, logistics and manufacturing. With the Blink(1), ThingM deliberately set out to learn how to conquer just those areas partly because they were missing experiences in retail.
There are common solutions to those problems. Startups can work with an incubator like HWY 1, folks who know the process. More established companies hire marketing teams, manufacturing engineers, and industrial design houses. These days, smaller companies can go to Kickstarter to gauge their market, establish buzz, and fund initial development. Yet there is something to be said for learning enough outside your comfort zone to know whom to hire and when an outside resource might be failing you.
Engineers can solve problems outside of engineering and, indeed, we often must do so in order to succeed as company leaders. After years of embedded software consulting, Elecia and I have both seen all kinds of companies. A few have genuine success because of both well-designed products and sharp business sense. Others have success in spite of being clueless about anything but engineering, simply because the market wants the product so badly. Most, however, fail due to inability to bridge the gap from solving the engineering problem to solving the product problem. Companies in that latter category usually couldn’t admit to themselves what they weren’t good at. A little bit of hubris (acquired while solving hard technical challenges) sprinkled on top is usually enough to lead to disaster.
A complication to all of this is that sometimes you don’t even know what skills you are lacking. Elecia often tells this story: “When considering contracting, I asked a consultant I knew about the most important part. I expected to hear about the networking or marketing parts that are often difficult for introverted engineers (like myself). She said the most important part is accounts receivable. I have, indeed, found that is often the case”.
Elecia learned a great deal about running a business by, well, running a business. Returning to full-time work after that stint of contracting, she was far more aware of everything: how billing worked, why accounting seems so rigid sometimes, the legal aspects of employees. In some sense her learning process was accidental (incidental, at least). Wouldn’t it be interesting to mindfully approach what you don’t know and go after it?
Perhaps devoting an entire product to that education, as ThingM did with Blink(1), doesn’t make sense for you (or your company). However, taking the time to cross-train to the business side will make you a better engineer. Instead of optimizing the code a little more or striving to get the cost a little lower, it might behoove you to understand the marketing. Instead of producing a new lower-powered variant, see what you can learn about improving the enclosure or industrial design. Even more radically: start your own small business, maybe one on the side that lets you see into the business depths most engineers shy away from.
Being a better engineer often means being a better marketer, designer, and manager, but you don’t learn those things by doing more engineering.
Elecia and I went into the interview a little perplexed at how ThingM had gone from making our valued I2C LEDs to the Blink(1) USB LED, a product that didn't fit into our weekend projects or our built-for-client prototypes. However, Tod Kurt showed us that companies can and should strive to improve in many axes beyond hardware and software.
Studio photos courtesy of Sophi Kravitz