The Intersection of Technology and Community

A revised transcript from our interview with Rob Lauer

A revised transcript from our interview with Rob Lauer, Director of Developer Relations at Blues Wireless, a company known for its cutting edge, and developer friendly, IOT technology. Including the Notecard swan and many more. Thank you for reading and enjoy the interview. 

Colby: Can you describe your role as Director of Developer Relations, because it seems like a coverall title for such a mix of technical and non-technical responsibilities. 

Rob: As you say, with developer relations, frame it as good or bad, it suffers from the fact that it does sit in the nexus between, marketing, sales, product engineering. To be really successful in the role, in any kind of role in developer relations, you need to have some traits of all those different kinds of individual contributors and roles in those different organizations.

I summarize developer relations as the Three C's; we're doing code, community, and content. For code, we work on the projects that you've seen on Hackster and contribute sample apps. And then on the community side, of course, we're charged with building, growing, nurturing, the community. Folks who are actively using our products and on the content side; doing video webinars, blog posts, that kind of stuff too.

Colby: So basically, the product's handed to you, and then you make all the content around it to teach people how to use it. And then you go market it to people who want to use it. 

Rob: And what differentiates us from marketing is that we are as authentic as we possibly can be. Mostly because developers can smell bullshit really quickly. So non-technical marketing doesn't work really well in these companies. They need to see it working in real life, and prove it out. That it's not just blowing smoke. To be able to tell an authentic story and to have some kind of engineering background really resonates with technical audiences.

Colby: Have you found any trouble getting the product from engineering and trying to figure out its capabilities? Or doing a project from scratch, cause no one's going to tell you if it's going to work or not. Is it mostly trial and error?

Rob: When I'm planning a project, in my head, slash on paper, can map out all the different components in terms of the hardware and then making sure that there's the right software. If I'm doing a project in Python, to make sure there's the right libraries available for all the different components. And once I at least have an idea that “oh yeah” I think this is possible based on code I've seen, or code I know I can write. Then I feel pretty confident. 

But it's a different story with our own products, ironically, because when I'm using third party components, I'm not diving too deeply into a lot of the functionality. Which sounds really vague, but let me juxtapose that to our products, which I am diving really deeply into and releasing new firmware features and new hardware releases all the time. And often there's a bit of a gap between us and engineering because they're building, releasing these features. Then I have to get up to speed and I need to know those inside and out. I have to be a literal expert versus using a third party where I just need to know roughly how it works.

Colby: And doing the projects, especially, cause I like to talk about open source a lot. A lot of issues arise in compatibility, I’ve found, with products and hardware, do you just trial and error to find open source tools? How do you go about researching and finding a good open source tool to use when you do a project?

Rob: A lot of it's referrals, a lot of it's looking at, you know, documentation. Are things well documented? Are there decent samples available? Is there a sizable community behind them? Are they well maintained? And even even well maintained can just be once a year or something to make sure that there's a heartbeat out there.

This is the core of developer relations is this concept of developer experience as well, and that's huge for open source. Are you providing an engaging developer experience from beginning to end, and removing friction at every possible point? That's the ideal open source journey, if you will.

Colby: Have you had any problems with open source? Cause what I run into a lot is, like you mentioned, not well maintained or bad documentation. Have there been any problems where you've had to make a major switch away from any open source tools?

Rob: Yeah. I mean I've certainly been luckier than most. And I have a background in engineering, so I do have decent technical chops. I don't consider myself an engineer today, but I can work around simple issues, and I know everybody experiences this; where recently I was working on a proprietary microcontroller that works with a dot net frame, a kind of a micro.net framework. 

But my background's in .net and C sharp, back in the day. So I thought it would be cool to work with C sharp on micro controllers. It works well, but I ran into a problem trying to get support for an individual sensor. I asked on their forum and they're like, “oh yeah”, you can do that, but you just have to dig up this five year old or 10 year old, some ridiculous C library and rewrite this part of it. And this is the bad part of open source. Where it actually becomes work for you. I understand I'm not maintaining anything currently, but I know the pain of individual open source maintainers. The shit they have to deal with from the community can be overwhelming to say the least.

Colby: Off of that, how much are you involved with the support side of things? 

Rob: So I do a lot of work on our forum. We have a couple different support avenues. We have a dedicated support team of two people right now, and they handle our, we don't have paid support, but it's basically email based support. Then I handle the forum side of things, so our public forum. Which is support and community, kind of wrapped up into one.

Colby: I went through the Blues forum and the documentation and tutorials which are really extensive. It's pretty cool to see that. Do you offer support on your own projects?

Rob: I will certainly answer questions. I get a lot of questions on Hackster in comments or private messages or whatever. I always answer every one of them as best I can because, and this is the reason I think that I've always enjoyed developer relations, that I can really empathize with people, especially beginners. It's how I build my projects too. I don't assume too much knowledge because I know what it feels like to start reading something and you're lost right away. 

Colby: Why did you choose Hackster as your main platform?

Rob: Cause of their reach, and Hackster just fits that right niche for us. It's not too hardcore EE cause I don't have an electrical engineering background whatsoever. So I'm focused more on the basic functionality of what I'm trying to do. Not the nitty gritty details of the boards and components and stuff. So it's the right audience for that.

Colby: Just to touch on a couple of the projects, because founders might want a prototype of something just to see how it works, and the bill of materials they have is for $20,000 for something like a speed radar. They have $20,000 in parts, and then I'll pull up your hackster project and make it for $300 or $400 total and that's it. When selecting components, is that just researching other projects or do you just pick those because they can do what you need them to do?

Rob: Most of what I do is really basic off the shelf, but obviously the Doppler radar for the speed radar project did require some research. I knew I was going to use a raspberry pie for that, so I was looking for a Doppler radar sensor with a Python library that was already written. 

Colby: I wanted to ask, when using different boards, because there’s differences from board to board and firmware to firmware. Even the differences between using a raspberry pi and an Arduino can be difficult for some, and then going to just a microcontroller that doesn't have a UI, it’s a huge gap.

Rob: When I started at blues about a year and a half ago, one of my first concerns were the things I was trying to do with machine learning. There's no way you can run these programs on a tiny little micro controller, right? So I started with the full size raspberry PI four, which was great for a lot of things. And then that's when I discovered edge impulse and realized that there was a lot more I could do on smaller boards. Over time, I've graduated to smaller and smaller, less powerful boards.

Not to toot our own horn, but actually I think the Swan microcontroller that we sell hits this sweet spot and it's been, frankly, underrated. In that it's using a really powerful but low power STM 32 chip. It's sort of ideal if you're running, especially, some heavy duty machine learning inferences on it. It performs surprisingly well. 

Colby: Can you touch on that Swan more? I haven't heard of that.

Rob: So we released it maybe nine months ago. I'm going to use a marketing line; it’s the most extensible feather compatible microcontroller, because we have little castellated edges around it. So you can expose a ridiculous amount of IO from the board itself. So if you're connecting a ton of peripherals, it's great there, but it's that combined with low power and then a powerful, relatively new, STM 32 processor. And it's certified with edge impulse. 

Also on the Swan, there's a little port that lets you hook up an ST link debugger cable. And this is another thing that was big for me coming from the web world, where building, writing, building, coding, deploying to a device can take a minute or two sometimes. So when you're iterating on these small changes, you have to recompile and wait 30 seconds for this to redeploy. By using the Swan with this debugger cable, you can do lightning fast deploys without entering into this bootloader mode and stuff. So there's a lot of nice features on it.

Colby: What is it targeted at? Is it a mostly general development board, like a pi, or are you targeting a specific use? 

Rob: I would say it's mostly pretty general. We were actually inspired to build it from one of our larger customers who had this need to expose a lot more IO than was available on a lot of existing feather boards.

We're trying to position it as a machine learning capable board. But to be totally frank, we haven't got a ton of traction with it. Its sales have been fine, but it didn't blow up like we were hoping. So I think it still has promise in the future.

Colby: Have you used it with anything yet? 

Rob: Have I used it? I don't know that I've actually used it in a public project of mine yet. But I do use it regularly. I love to prototype stuff in Python, even though it's not a necessarily realistic production language. It's interesting too, not to get off on a different subject, but our analytics, with our guides and tutorials, is almost a 50-50 split between people using Python on pi's versus arduino or C with other microcontrollers and stuff.

Colby: Speaking of the Swan and everything, I want to talk about some of your other products. The most popular seem to be the Notecard, Notecarrier, and the pie hat. Are those the two or three big ones?

Rob: Yeah, really the Notecard is the core of what we do. Ray Ozzie started the company in 2017 officially. But it took a couple years before they launched publicly with the Notecard, but the whole point of the Notecard was to make cellular IOT cheaper and easier to use.

While the Notecard still remains the core of what we do, we branched out into a wifi Notecard and we are slowly but surely building off of that. We initially thought of the Notecarriers as a prototyping tool, because we expect when somebody's going to go to launch at scale with a Notecard, they're going to spin their own board and they're going to embed the Notecard into their own custom board. But a lot of people are finding that the Notecarriers offer onboard antennas that are really nice now, really easy access to some pins on the Notecard, solar T port, etc... that they're actually going to production with some of our Notecarriers as well. 

Colby: Are you targeting both commercial and hobbyist people for these products? 

Rob: Yeah, for sure. If you look at our website, there's success stories or use cases, and that's where we're starting to publish some of our larger customers. We have a couple really big customers that we can't talk about yet, but that's how we're going to be successful long term is by onboarding these customers. 

But my team doesn't work with the large customers. We are focused on the individual developer and making individuals successful, even if they are just a basement hacker, hobbyist kind of person that's fine. We know we're not going to build our business off of them, but every once in a while, those people who are tinkering at home go back to their company and they're like, “Hey, I was successful using this Notecard thing, let's try this at scale”

Colby: What people does your team consist of at Blues? Because there's a huge difference between engineering and then the task of teaching people how to use it. And there's also a huge difference between hardware and software and hardware and software engineers.

Rob: I'm leading a team of one traditional developer advocate. Who can pretty much do anything, he's a really good speaker, instructor, he's a fantastic writer. I also have a somebody who's more traditionally a firmware engineer, so he is a little more hardcore, what I consider hardcore. So he's got a great background there. And then we just hired a community manager as well to handle more of the scaling and maintaining of our community as well. So combined with the four of us, we have pretty good technical backgrounds and those soft skills that are required to be successful in a technical role.

Colby: For tutorials and lessons and all that, there's the Notecard and all the hardware and then also there’s Notehub IO, and that's developed a lot, even in just the past year. Have you been a part of that and developing what that looks like and how to teach that to people as well? 

Rob: Yeah, certainly on the instruction side. We're not involved as much on the engineering side, the way we interface with our product and engineering teams is mostly to provide feedback from customers to them. So obviously if there's a bug, that's priority one, but when it comes down to it, like I said at the beginning, our job is to remove as much friction as we can from the developer experience. So if they're having problems with Notehub, then we definitely want them to know about it. But on the tutorial, instruction side, for sure, we're doing workshops, we're finally doing them in person again. 

Colby: What do those look like, the in person workshops? Do you just hand out a bunch of boards? 

Rob: We provide custom built hardware for these workshops, and you're going to love this, but we call it the hammer of blue. So we hand these out because it's a fun thing to use. Obviously at a workshop you want something that's really fun and engaging if you're going to sit in a room for two days, but it's got components and sensors on here and it does have a Swan at the base. And it has all the raw materials you need to be able to build a pretty engaging project. 

So we walk people through just this one piece of hardware, getting started with the Notecard, sending data to a cloud, building a machine learning solution that uses the accelerometer on the board and generates inferences to identify different types of motion with the hammer. And we can do all three or four labs with that one piece of hardware, so it's pretty fun. 

Colby: Off of the routing and everything, this is probably hard to answer, but what projects use blues the most often, it's probably not a specific category, but for example; I really like it because routing data from one place to another has been the hardest part of some of my projects, and Blues is actually really good at it and explaining how to route it to another source. Are there specific types of projects that use Blues more than others or is it pretty much any project that needs to get something to the cloud or route it?

Rob: You know, it's a blessing and a curse in that, when you talk about IOT, being internet connectivity, there isn't a target market for us. Which is great, in that anybody can use the Notecard. But then for our marketing teams anybody can use us, so who the heck do we even market this to, and that's again, blessing and a curse. We apply to everything, and if our marketing team has had one struggle, it's been trying to focus on, they call it the repeatable sales motion, but trying to repeat some kind of niche market that can utilize us. We're a victim of our own success in some ways. 

Colby: I wanted to, before I forget, mention your education and background and degrees in behavioral science. How did you move from that into engineering? Because that's a pretty big jump between two very different fields. 

Rob: When I was growing up, I was always into computers, but I never thought of it as being any kind of a career. I thought I didn't like programming back in the day. I just liked to do some gaming and tinkering. 

I ended up getting a degree in behavioral science, because I thought I was going to go to law school. And then my senior year of college, I got a job doing computer support at a department on campus. And my boss there ended up being a long term mentor for me and really showed me how cool it can be to write some code and push data to a database.

From there I got into a lot of web development and engineering. I had a consulting role and worked at the University of Wisconsin for quite a few years. Where, I realized that my real love, aside from engineering, was in instructing, building content, writing about what I'm doing, which is where my degree came in handy, because I was doing a lot more of those soft skills, if you will, in terms of writing and speaking and such. So that's why I think I've been successful in developer relations, because of the combination of my technical background with some of the writing skills.

Colby: Which is huge, because a lot of engineers and technical founders have a really hard time explaining their tech to people. And since you went to school for a non-engineering degree and then became a software developer, how did you learn those technical skills on your own?

Rob: I think what it comes down to for me is, and we've identified this as well, in developer relations, that there's a bunch of different types of learners. There's people who like to watch videos and learn that way. There's people who like to read through tutorials and do it step by step. Then there's people who like duplicating a project, and this is how I learn best. I'll take a big chunk of code that does one thing, and I'm like; “You know what? I wanna do this one thing that's a little bit different”. So then I learn by going through the code and identifying what I need to change. So it's like cloning an app, building it, seeing how it works, and then starting to make changes and build off of that. And then maybe eventually rewriting it with my own knowledge. 

Colby: Deciding to become a software developer, as that’s very technical, sitting at the desk and just coding all day, and then moving to developer relations. Was it hard to decide between those two or did you know you wanted to move on and be able to do the education part and accompany it with the technical stuff. 

Rob: I knew I needed to move on. I had been in a pretty traditional developer role for quite a while. I still really enjoyed it and do enjoy it. I'm definitely an introvert at heart, so I'll just sit at a desk all day and code and be perfectly happy. But I also knew that I had a lot more to offer and I think that's why at the end of the day it was pretty intriguing to get into developer relations.

Colby: Was it difficult to move from a technical role to a management role? 

Rob: I love the idea of being a manager and leading a team, but I've only been successful when I've hired people who have been really fantastic and very self-motivated and self-driven. I'm not good in a manager role when I have to do a lot of checking in. “Hey, did you get this done? When do you get this done?”. So while I do lead a team, I take pride in the fact that still probably 50-60% of my time is spent doing individual contributor tasks that anybody else would do. 

Colby: I wanted to touch on some other products and newer products from Blues. I saw the air note and there's a few that I don't think I've seen a lot about before. And what's coming in the future

Rob: In about two or three weeks, we have a new Notecarrier coming, that's exciting. We have the Notecarrier AF today, which is our largest Notecarrier. That's got the feather socket on there. We have a new, pretty dramatic revision of that coming out, it's a smaller form factor. 

Colby: Can you describe the Notecarrier AF a bit more?

Rob: So the AF is the one that we're replacing and we're calling the new one, the Notecarrier F to try and simplify our naming a bit. So it'll have a feather socket, it'll have quick ports, threading, peripherals. There's a bunch of good stuff. That's a mid-size product release for us. 

And I believe in August, we’re releasing our Sparrow project, and this one is pretty interesting. The idea behind Sparrow is that people will come to us and say, “I need to monitor a warehouse and I need to monitor 50 points within this warehouse, but I don't want to buy 50 Notecards to do 50 different points.”. So what Sparrow does is provide a single Notecard gateway. It's got a gateway with one Notecard in it, but then the gateway communicates with n number of nodes over LoRa. So you can have a bunch of different LoRa sensors with a long range. And the gateway will, using some novel techniques of polling the individual sensors, one at a time, will continually gather that data and then pipe it up to the cloud through that one gateway. So it's really great for folks who are scaling to a lot of Notecards and sending a lot of data.

Colby: That’s interesting, because projects with a pi or Arduino, you would have to use 50 of them. What are the differences between the different Notecarriers, are those just older products or are those completely different?

Rob: They're all different in their own ways. The AF and the F, the advantage of those is that you can drop a microcontroller or a feather compatible microcontroller right onto them, so that's nice. Then you have the A, that's the black one that we just released. That's my go to, really generic, it's got great onboard antennas on there. You can access virtually any pins on the Notecard with it as well. You can connect all kinds of stuff to it. It's really just a nice do-it-all. 

The B is what a lot of people go to production with actually, because it's a really small form factor. It's barely larger than the Notecard itself. But it doesn't have any onboard antennas because the size is so small. And the pi of course is the only one that works with the pi hat. We are looking at doing a new revision of the pi hat as well, so that'll hopefully be coming by the end of the year.

Colby: That's probably the most popular with the hobbyist people too, something you can just click on to a pi. Are the A and B standalone or do they go with microcontrollers usually?

Rob: Nine times out of 10, you are hooking them up to a microcontroller. One of the interesting things, and maybe you saw my project on the power outage monitor. That's a really interesting way that we're using the Notecard firmware, adding as many capabilities as we can to the firmware that don't require a host to function. So that's just the start, there's a lot. And I know the team is working on some other features as well that we can use for those really specific use cases. 

Colby: I also wanted to touch on your crypto project too, because I've never heard of using a pi for crypto. I saw that you didn't get much, but it's a pretty cool project with solar power and everything. How did that work out? Did you use wifi or cellular? Did it take a ton of bandwidth? 

Rob: That was the one project where I was cheating by including the Notecard in there, because the Notecard was not necessary in any way really. Aside from just reporting data to a cloud dashboard. I can't remember how it came about. Obviously during the crypto boom of the last couple years I got to thinking about it, and I stumbled across somebody who was talking about trying to mine on an array of pi's and I was like what would happen if you just took one pie? And then I was like why don't we try and make this relatively sustainable and throw a solar panel on it as well? The results were as expected, but it was fun to do a proof of concept. 

Colby: Now that Blues is growing so much, do you see people on the forums helping each other and people doing their own projects online? Do you get to find those a lot? 

Rob: I mean, that's probably the most satisfying thing that we see over time. When anybody answers a question on the forum, that's amazing. That's literally taking work off my plate. But more importantly, when we see folks posting Hackster projects using the Notecard, purely organically, that's amazing. That's when we know that we've really done our job.

Colby: Are you partnering with any other companies that have open source products, like edge impulse.

Rob: We do a lot of work with folks like Balena, datacake, ubidots, Losant to a certain extent. I don't know how much open source really is involved with those platforms, but we do a fair amount of work with them. We have this unofficial kind of partner program where there's a host of companies that we'll work with pretty closely. 

Colby: The edge impulse one is really cool.

Rob: Yeah and it's definitely our biggest one. They're the most engaged ones to work with.

Colby: How did that partnership happen? Was it from your project or was it before that? I actually found out about edge impulse, through your project.

Rob: As soon as I built that project using edge impulse, folks from edge impulse started reaching out to me and some people at our company had a preexisting relationship with some of the folks there as well. 

They're in the same boat as us, they're trying to increase awareness and adoption. So they love this idea of people building projects on their platform and they're always willing to work with us really closely.