Interview with Jason Hintersteiner, CTO at Imperial Network Solutions

Ledge: Hey, Jason. It’s great to have you on. Thanks for joining us today.

Jason: Well, thank you, Ledge, for having me.

Ledge: Can you just give like a two or three minute background story of yourself and your work, so the audience can get to know you a little bit?

Jason: Sure. I’m a CWNE, which is a Certified Wireless Network Expert. They’re only about 300 of us or so in the world as at the moment. It means I know a ridiculous amount about Wi-Fi.

I’ve been working in the Wi-Fi industry since 2008, so almost 11 years now. I did it after getting my MBA. I have engineering degrees and I worked as a systems engineer for about 10 years in the chip set manufacturing industry, so making the machines that make the computer chips. I went for an MBA at night, finished the MBA and then decided I want to go do something else.

I went to go work for a startup company that was doing Wi-Fi in apartment buildings and hotels. They hired me on to run their engineering department. I arrived the first day and I discover I am the engineering department. Then, two weeks into the job, they send me down to Sugar Grove, West Virginia – which if you don’t know where that is, it’s basically go straight to the middle of nowhere and hang a left. We had a mesh network out there.

This was back in 2008 when most stuff was still single band 2.4. We had a mesh network out there on the residential portion of a military base. There was nothing to do out there, so these guys at night were just hardcore gamers. It was World of Warcraft and stuff like that in those days. They were just hardcore gamers.

Of course, it was only a Wi-Fi connection and if the Wi-Fi was not working right, their game would screw up.

It was really a trial by fire, getting into this industry and getting into this business. We got the network working. I spent about six years there doing hundreds of wireless deployments in apartment buildings, hotels, student housing, hot spots, you name it. It was very, very interesting work.

After that, I did some private consulting for a while and then I started working for vendors. First EnGenius and now LigoWave – both of them are manufacturers of Wi-Fi access points and related products.

Ledge: We’re mostly software engineering folks here, but I just think there’s just this amazing touchpoint that what you do, it’s like you build the highway. IoT now is starting to… Everything is just Wi-Fi-enabled.

What do we need to know on the software engineering side that I think that your expertise brings to the table? It’s almost taken for granted. You just expect it to be there. But it’s not always there. How can we make fault tolerance and security and all those things built into the software? That’s really important stuff now.

Jason: You’re right. Wi-Fi is essentially the backbone. It’s the support infrastructure that all this stuff runs on. Certainly, with IoT and everything being in the cloud and Software as a Service and Networks as a Service, and pretty much everything as a service now, all relies upon Wi-Fi to get that data from whatever devices that you have out in the field, whether they be cameras or IoT sensors or thermostats or home stuff, back to some server on the internet.

All of that requires the Wi-Fi to be working, and working well. Especially if you’re a hardcore gamer or something like that, it’s got to work really fast and have very low latency. Wi-Fi is really useful for that, but it’s also one of those systems that’s easy to mess up if you don’t know what you’re doing. It’s hard to get it right and it’s easy to get it wrong.

As an industry, we’ve sold everybody on how easy it is to deploy Wi-Fi. I just go to my local box store. I buy some fancy gadget with the antenna sticking out of it. I plug it in and boom, I got Wi-Fi. Yeah, for really small deployments that works well. But as you scale up, if I’m in an apartment building where everybody’s got one of those and they’re interfering with each other, I’m going to have a bad day.

Then the software systems and IoT systems and all the cloud-based stuff that relies on that to be working well is going to have trouble. Your network and your applications and your software are only as good as the infrastructure that it’s running on. It’s like having a Ferrari and I’m driving it on a pothole-ridden road on the back streets of New Orleans. I’m not going to go very fast, not because the car can’t go that fast but just because the roads can’t support it. The same thing is true in Wi-Fi.

Ledge: On the software side, how can engineers build better software to be almost good drivers on that highway? If you’re building that base level road that’s the most critical thing, how do I become an engineer software to be the best citizen, if you will, on the network?

Jason: The important thing is be careful about what data you really need to stream versus what you can process locally. Obviously, that’s very different for different applications. You take video surveillance, which is something that I do quite a lot of, do I push an uncompressed stream over the network, which is going to suck up a lot of bandwidth, potentially be interfered with, and then if I start dropping frames, I’m losing video images? Or do I do that compression on the camera and then I’m sending much smaller pieces of information?

Anything that you could do to get the amount of data down, to get it to be less real-time critical, will make it more robust.

Then, from a security standpoint, it’s amazing to me how many IoT devices and stuff out there have no concept of security whatsoever. Security is one of those Defense in Depth kind of strategies. It’s the belt and suspenders approach. I need security everywhere on my network, from that end user IoT smart thermostat, to my network, to my internet connection, and then ultimately to my server where I’m processing that information and relaying it back to customers. I need security along that whole chain.

People assume, oh, I’m just using a WPA2 connection so it’s encrypted. Well, no, it’s encrypted along part of your network, it’s not encrypted along your whole network. You got to be thinking about security holistically, especially in this day and age. You can see a lot of companies getting in trouble for not doing that.

Ledge: You talk about your multidisciplinary approach to education – multiple engineering degrees and then an MBA. How’s that fit together in the world? Why’d you do that? You can get paid a lot of money as an engineer.

Jason: Yeah, true.

Ledge: What else was added to your world because of getting a business education?

Jason: It helps. Right now, what I do a lot of is sales and marketing. Right now, what I’m doing is actually selling Wi-Fi product and working with customers on various projects. All the way from, I’m doing a private house with three or four access points to large arenas or deployments with hundreds and hundreds of access points.

I found that my background – my degrees are actually mechanical engineering, which is odd because it has nothing to do with what I do now. But it taught a method of thinking. It taught a method of approaching engineering problems that I find even most other people in this field don’t have. That perspective is very holistic.

Plus, when you’re talking to customers the business aspects of, how much is it going to cost, how long this is going to last, how much support is it going to need? Some of these are not necessarily technical questions but are important for the customer. You need to understand how the customer is actually building his business and how he’s making money in order to properly convince the customer that, no, this is the right solution. It’s not just because it’s the right technical solution, but because it’s also the right business solution and will meet your business needs, and will meet all of the requirements, not just your technology requirements.

Ledge: You talked about that engineering mindset that you bring to the table, that problem-saving mindset. I hear that a lot. I ask a lot of technical leaders on the software side, now how do you evaluate a really great A+ engineer?

Invariably, of course everybody wants to know… The table stakes are those technical skills. That’s just expected. But the way to rise above is going to be that problem-solving and communication ability, soft skills.

More and more and more, we’re asking engineers to think and act like business stakeholders. I don’t know if you see that in the field.

Jason: Most engineers are pretty bad at it, to be honest. I’ve worked with a lot of engineers over the years. Few of them are good at it, most of them are bad at it. We tend to think of, you have the engineering track and the managerial track. Then the people in management don’t really understand the technology, and the people in technology don’t really understand the business side of it and that human relations piece of it.

It’s all about building and sustaining relationships. I don’t want to speak bad of either my own company or any other company, but I don’t necessarily need the Ferrari. I don’t need, necessarily, the best and the latest and the most expensive and the most hardcore product for most applications.

There’s a lot of marketing hype out there that every vendor does – and it’s not just in Wi-Fi, I see that in software engineering, in applications and so forth. The job of a good engineer is to actually cut through all of that and go, “You know what, this is what I need.” Maybe for some applications I need all these whiz-bang fancy features and so forth. Okay, if I need them, then I have to pay for them. But if I don’t need them, then if I go that route then I’m paying for them anyway, even though I’m shutting them off and not using them.

To me, the sign of a good engineer is understanding, don’t listen to the marketing fluff. Actually understand the true requirements, what the customer and what the application really needs. Then pick the best solution based on that. Not based on, oh wow, we have a new generation of Wi-Fi so I got to rip out all my old stuff and put it in. Well, maybe you do and maybe you don’t. Most of the time, you really don’t need to for very…

Ledge: To paraphrase you, it’s like right tool for the job at hand.

Jason: Absolutely. Again, you mentioned the soft skills. It’s not just a matter of saying, “Okay, here are the requirements,” it’s those soft skills, because often customers don’t give you… It’s not like we were taught in engineering school, is like, okay, boom, here’s the problem. Often, you have to pull that from the customer, sometimes over the course of several conversations where the requirements are not clear upfront.

As engineers, we like to go, “Oh, well, this is similar to what I did before and so I’m just going to fill it in.” Sometimes that’s not correct. Sometimes the customer has a different expectation and those expectations are unstated, yet they’re still requirements.

You need the soft skills in order to be able to sometimes pull that from the customer. The customer is not thinking in engineering terms. The customer is not thinking about problem-solving. The customer is just thinking, “Hey, I’m talking to you because I need something that does X.” In reality, that X actually maybe consists of 10 different things and they’ve only told you one or two. Oftentimes, you need to be able to have those soft skills to have those conversations and actually listen to the customer.

My boss is a big one on saying, basically, spend most of your time listening and very little of your time actually talking. That it’s more important to listen to the customer and glean, in conversation, what they actually need.

Ledge: Yeah, and what assumptions are they making? “Well, I just thought it did that. I didn’t think I needed to ask you for that thing because that’s what they all do.”

Designing solutions is I guess medium-agnostic. It doesn’t matter if it’s hardware or software or even a business process design. It comes down to, what I’m hearing a lot, is the convergence of this product syncing with engineering. You get down to that and it’s just over and over again like customer empathy. Sit in the seat of the user. Sit in the seat of the customer. You really understand and facilitate them to talk about what they actually need.

I assume that happens a lot.

Jason: Yeah. As a young engineer, when I was fresh out of school and wet behind the ears, I remember in my first a senior engineer saying, “We should make all of you junior guys go down to the factory floor and just build tools for six months before you actually start designing anything.” At the time, I thought the guy was just being a curmudgeon.

Of course, as I’ve gotten older and more senior, I don’t know, I’ve adopted the same curmudgeon attitude because I actually see the value in it now. I didn’t necessarily 20 years ago, but I see it today.

I would actually go a step further, which is what you said, which is I’d actually make our engineers use our products. I’d make them actually go out and have to deploy stuff. Then they’ll see, well, how difficult is this thing to install? How difficult is this thing to program? How difficult is it to use?

Even in the software world, it’s like, okay, I’ve got an app on my phone. We all know that some apps are really easy and intuitive to use and some apps are god-awful. I’d make the software engineers actually have to use the app for various things. You know what? They’ll immediately see right away what’s wrong with it and then they’ll go back and they’ll make better designs.

Ledge: In our industry that’s known as dogfooding. Eat your own dogfood, right?

Jason: Eat your own dogfood? Yep.

Ledge: Yeah, absolutely. Talk to me about some more stories or some good, interesting learning experiences; rising from the phoenix of failure to opportunity. I just think that those are the places that we can all draw from each other’s experience.

Jason: There are several war stories. Some of them are very entertaining.

That that I used to work for years ago, we had a building in New York City where the studios went for like four grand a month and most of the apartments were like seven or eight grand a month in rent. The building was full. Primarily, it was like 20 and 30-somethings. We could never figure out how people afforded to actually live in this place. One day, we found out.

We had problems with our network controller, which was our central router and portal. It was getting too much traffic and it was getting overloaded. We ultimately wound up putting in a bigger, beefier server to handle the load, because what we had there just couldn’t handle the traffic.

I remember we kept getting complaints from this one woman who was busy screaming at us saying, “You got to get the internet working. You got to get the Wi-Fi working because that’s where I make my living. If the Wi-Fi is not working, I can’t make money.” What did she do? It turned out that she did performances on Second Life, where clothing was not part of the performance, at least not for very long.

Our guys actually wanted to keep streaming her service to monitor her internet connection, but we had to say no.

Ledge: Right. You don’t know what you’re going to run into.

Jason: Yeah. Some of the stuff you run into is just amazing.

It’s amazing when you’re dealing with… It depends if you’re often B2B or business-to-business or business-to-consumer. When you’re in business-to-consumer, sometimes you realize that people are just crazy. Some people are just nuts.

We had one guy, we had done an apartment building and they had put the APs in the bedrooms. For varying reasons, you actually want to put the APs in the apartments and not in the hallways, to get better signal, get it closer to clients and so forth. We had a design where they put the APs in the bedrooms. They went and deployed it, but they didn’t turn off the LEDs. Typically, especially if you’re going to put them in bedrooms, you typically will turn off the LEDs so they’re not bothering people.

This particular model of access point just had really, really bright blue LEDs. If you turned off all the lights, they would light up a room. They were just unnecessarily bright – but that was the model that we were using at the time and that’s what we deployed. Of course, they didn’t shut off the LEDs, so we were getting lots of complaints.

I remember we got a complaint from one guy who had unplugged this thing, because it was in his bedroom and it was keeping him up at night. Then he was calling to say that his Wi-Fi had no service. We went and looked on line, “Yeah, the AP in your apartment is offline.” He’s like, “Yeah. I unplugged it because the lights are keeping me up at night.” It’s like, “Well, if you unplug it, how do you expect to get Wi-Fi?”

Ledge: As implementers, how do we expect the customer to not want to get sleep? It comes up to that game planning and laying out, how’s this actually going to be used in the real world?

Jason: It was an understandable mistake, because normally in most deployments at that time, we did not turn off LEDs. But then again, in most deployments we were not putting them in bedrooms. Usually, if you’re doing an apartment, you would put it in the main room and then you’d have the bedrooms off to the side. Then, okay, if the LEDs were on it wasn’t such a big deal because nobody was sleeping in there.

This particular deployment, the way the wiring was done and so forth, they wound up in the bedrooms and so it was an understandable mistake on our part. Again, it was dogfooding. If you made somebody live in the apartment for a couple of days, you’d immediately see what the problem was and you’d immediately go in and just fix it.

Ledge: You’ve been self-employed. You’ve been at startups. You’ve been at larger firms. Just maybe a couple of career nuggets that have been helpful, for our professional freelance audience. What’s going to work for them?

Jason: I think it’s important to understand your system end-to-end. Don’t just think about your little piece of it.

Systems now are so complicated, everybody tends to specialize and have their own little piece of the puzzle. But one of the things that distinguishes a senior engineer and even an architect from that is, I can’t just think about my little piece. Even if I’m building a complex system with lots of moving parts and lots of moving pieces, chances are that that’s one piece in a larger puzzle.

Even back when I was doing semiconductor manufacturing, we built the tools that made the computer chips. As the chips got smaller, the tools wound up getting larger and more complicated. Each of these systems that we were building were very, very complicated, had very tight tolerances on everything, and very stringent hardware and software requirements and so forth. All of these different systems had to play together nicely as a system.

That whole machine, with all of its moving parts and everything that was going on in it, was still just one step in the factory that it was being installed at.

It’s not just a matter of understanding your system, but it’s really understanding the context of how your system is going to get used and what’s actually important to the customer. Which features are really essential and which features are nice to have.

That is not always obvious. That’s not always stated by the customer. Sometimes even the customer doesn’t know, until they start using the product and then all of a sudden they’re trying to do something that nobody thought about. You need to have that flexibility.

I think understanding how your product is going to get used, no matter what you’re engineering. Whether it’s a software app or an IoT device or a Wi-Fi network, you need to understand how it’s going to get used.

Ledge: Great insights. Jason, I appreciate it. Thanks for spending time with us today.

Jason: Sure. Any time. Thanks for the opportunity.