Our guest for this week is Jared Huke, founder and CEO of Daito Design. Daito Design is a strategy, consulting, and design firm focused on creating impactful innovations for enterprises.

In this episode, we talked about how user-centric design can improve the success of IoT solution deployment in the energy sector. We also explored the complex interactions between user experience, business design, technology development, and risk management.

Key Questions:

• What is the landscape of digital projects in the energy sector from a user-centric perspective?
• How does the energy sector differ from other sectors in terms of interface?
• How do you align your business model to provide a user-centric design and functionality in IoT service?

Erik: Jared, thank you for joining us on the podcast today.

Jared: Thank you for having me.

Erik: So, you run an interesting business. You're in an interesting focus area. Let's say, the energy sector for a digital company and then with a Japanese name and theme behind, and of course based in Amsterdam. So, there's got to be some background story here. Maybe that's a good place for us to kick off. I suppose you're Dutch originally, although I know you were over at University of Texas. You've been kind of hopping around the world a little bit. How did you end up setting up a digital design company focused on the energy sector with a Japanese name in Amsterdam?

Jared: Well, yeah. So, I'm actually not Dutch. We're even more inexplicable, I guess, in some ways. Daito Design is really focused on this transformation of these legacy companies into digital space. With that, there's a lot of muscles that they've had that they have to redevelop, specifically I think mobility in a big way — moving to mobile applications and IoT in connected devices really forced their hand. They couldn't just build these big, ugly, multiscreen software systems that they'd gotten away with, where they were more engineered than designed.

I'm from Austin, Texas originally. I started at the University of Texas in physics and astronomy. I ended up with a fine arts degree with a concentration in design theory and methodology. The '90s were a fun time. I ended up taking a job after a referral from my first company. That was a virtual reality company in the mid '90s. That took me to Southeast Asia working on various software and digital marketing products.

In the middle of all that, I had a sustainable building materials and furniture company. I came back to the States. I worked in the agriculture space for a while, which I find somewhat again inexplicable in terms of some of the decision-making. I had found myself in China working in luxury brands of TAG Heuer, L'Oreal, Armani. Then ultimately, I needed to find my way back to the States after expatting myself for a bit.

I was working in Houston with a company that was really focusing on mobile application engineering. They really didn't have a design practice. With mobility came this real urgent need to get the user experience correct. Because if you have something that's vibrating non-stop in your pocket or your wearable or something like that, the experience starts to really matter. It's not just a desk somewhere with a bunch of alarms or alerts going off. It's on you at all times. So, that forced this observation or this need to get into the user experience with these heavy enterprise clients.

Houston, Texas surprisingly has a lot of energy going on. That's oil and gas. That's utilities. There's some very interesting work with some nuclear companies as well. I decided to continue that on. That was sort of where Daito was born from. It was from this idea of bringing some of that luxury brand touch and feel that I was working on in China into this industrial steel toe boot and hard hat space that was trying to figure out how to digitally transform and had a procurement, and IT, and cultural barriers to innovation that user-centered design was able to penetrate and go through that.

In that space, we brought in the practice of human factors which is a variant of the user research world, and brought that together with this high-touch, high-finish design approach. That seemed to be a pretty winning combo. So, that idea of craft and craftsman was where the idea of Daito and this Japanese concept of 'shokunin' or honorable craftsman came about.

We wanted to be a different agency. We wanted to be an agency that was humble and a quiet companion with these giants that we were with instead of coming in as a lot of the consulting firms or larger design firms that had a lot of arrogance and hubris, frankly, when they would come to these innovation projects. I'm an aikido practitioner, so we do a lot of sword work in Aikido. We're trying to find a name that sounded cool and touched on this idea of this perfect tool at the sight of these giants. That was the genesis of Daito.

Erik: Okay. Fascinating backstory. I don't know if you're aware, but I'm sitting here in Shanghai right now.

Jared: Oh, I didn't realize that. Well, please go get some xiao long bao for me. I am desperate for some solid dumplings. Yang would also totally be acceptable. Please indulge yourself for those of us that are stuck abroad.

Erik: Well, I wish I could fly over for a visit and bring some wai mai, but I haven't been out of the country obviously for a couple years now.

Jared: Yeah, it's been a bit restrictive lately. My mother-in-law just returned back a little over a month ago. She actually just stopped through LA. She just arrived and has been quarantined as we speak. So, I guess stay put is kind of the theme right now in China.

Erik: Yeah, exactly. But this is a fascinating background. If you look back, before I was born, let's say, a lot of cutting edge was coming from industrial. I guess that is still the case, but it does feel now that consumer is moving faster in most areas. Of course, luxury moves very fast in specific areas around the user experience. So, being able to walk that back to industrial makes a lot of sense. Are you right now, I guess — let's see. It's eight years. So, you must be in Amsterdam, not in Austin. Is that your base right now?

Jared: Yeah, I'm expanding Daito in Europe. So, we've been here for about a year in Amsterdam. There's a lot of pro-business treaties that allow U.S. companies to expand in the Netherlands. Shell is one of our clients. So, there's a lot of reasons for us to be around where the Dutch are. There's a lot of energy happening in the Netherlands. Whether that's solar, offshore, or traditional stuff, there's a lot of innovation here, a lot of interesting hydrogen work that's happening in the area.

For us, it just seemed like a logical extension. As my backstory implies, I don't tend to stay put for too long. I guess, we were just in the mood to try somewhere else. The Dutch have been very gracious in having us. Our kids are in Dutch public school and all of that. It's so far been a lovely experience.

Erik: Great. Well, it's a great country and a great business environment, so that makes a lot of sense. Let's talk a bit about the energy sector and user experience. Because although the story that you just spelled out makes sense, you also have this backdrop of tremendous amount of regulation and legacy infrastructure that's 30 years old or older, and probably priorities that are not so much oriented around how convenient this is for somebody who's on the ground, on a site, but much more maybe some financial metric, which obviously matters. But you, I would imagine, have different tensions in terms of priority. Maybe we can start at a high level. What is the landscape for when you're looking at a software or a digital project in the energy sector, and you're trying to approach it from a user-centric perspective?

Jared: It's an interesting world. Each of the energy sectors that we operate in — that's the traditional oil and gas, nuclear, solar. We got some interesting things happening in wind and some aspirations towards some of the emerging hydrogen economy — they all have some sort of different kinds of constraints. There's as simple as things explode in oil and gas. They don't do that as much in nuclear, or if they do, you don't really have any other problems because it takes care of the whole area. Radiation being quite a theme when we're working in some of the older plants.

These environments, they have very different regimens about them and cultures about them. But at the end of the day, they are all trying to do the same thing, which is do more with less. None of them have as many resources as they would like. They're all very nervous about what's coming. The war in Ukraine has added several logs to the fire of uncertainty around hyper-volatility, supply constraints and whatnot. Europe is about to have, I think, a fairly uncomfortable winter, which is we do inspire a lot of change of consumer and industrial behaviors around what do we do when these things start moving around very dynamically.

From a user-centered perspective, I'd say the business goals are often fairly similar. There is a rising interest in automation — how ultimately can we do more work with less people. We saw that with lease operators, where a lease operator would be going around to 15 to 30 wells. They wanted to take it to 50 to 100 wells in a day for one operator to manage. With nuclear, it's hard to recruit for that. There's a large retirement workforce and all of that. They've got a lot of pricing constraints. Oil and gas, the writing is on the wall, I would say, in some ways. There's still going to be some oil and gas in the foreseeable years. But obviously, the EVs and a lot of the decarbonization efforts are making — I think they are none ignorable facts at this point.

So, they're all trying to figure out how to stay relevant, how to automate, how to do more with less. Many of them, I would say, believe that technology plays a key role in their ability to do that. Every single one of them has significantly failed efforts in attempting to do often some very simple things — whether it's just going to some basic digitized workflows, trying to remove paper from the work systems, et cetera. All these industries have major deployment failures.

Typically, from my experience, that usually falls down because they did not do their diligence around the user experience piece of that. They might have the code generally correct, or functional, or performing. They've got a great business case for it, maybe. But when it comes to the users — these are scientists, engineers, and businessmen — that as for certain demographics are not necessarily renowned for their empathy and their ability to understand the psychology of people that are trying to do very challenging work in very difficult environments.

That's what we really enjoy. It's those really hard-to-reach environments where you have people that are in highly noisy environments, heat stress, radiation, et cetera where they're trying to solve these challenging problems. They need an interface to a phone or an iPad or some other device that is there with them and not making their job harder. More often than not, poorly considered software slows down people's work, at least on the first often three to five iterations of the software to get it to something to actually start to see those return on investments.

I think that's a lot of our business model really is. It's around those efficiencies on the execution side, helping them figure out what it needs to be quickly so that they can build it correctly. That churn, that risk associated with not doing the user experience work, we've seen it really blow up in people's faces and are often brought in to rectify a software that was ill-conceived or ill-executed according to the user's perspective.

Erik: Interesting. So, we do more work here at IoT ONE in the manufacturing sector being here in Shanghai, in China, and then in more traditional enterprise. If I'm just thinking, as you're talking through the user experience, I'm thinking most of the cases were either working then in a very controlled environment — a factory where there's a dedicated network. Or, we're working with different people who might be at very different levels in the hierarchy, but they're all sitting at a desktop computer, basically, or they all have their mobile phone. Even though they might have different permissions, have different views, and so forth, they can fundamentally work with the same interface.

Now as you're talking, I'm thinking about somebody who — I don't know. It could be a solution that's being used by middle management or senior management at headquarters, and then also being used by somebody who's on an oil rig who has to keep his hands free, has oil on his hands, et cetera and not just needing different views but also maybe even needing a different interface or a different way of interacting. Am I going too far here? Is that one of the challenges? I'm thinking, what differs here in this sector versus the sectors that I'm more comfortable with?

Jared: Well, I think it would be adjacent to what you're talking about. Because you have shipments that are going in and out of those factories and warehouses. There's packaging and whatnot. There's deployment of whatever devices that you're making. There's maintenance on the devices, changing batteries or sensor calibrations, and things like that. Also, with what you're making, what does that connect to? How do people ultimately use those devices in a way that is successful? Because if that end user was successful, and the business that deploy those was successful, your orders will increase, et cetera.

It may be that in the manufacturing space, it's a very controlled, more desktop environment. But I would think that there's probably maintenance organizations at the warehouse or at the manufacturing plants that are mobile. They're walking around there. They're popping the hood on things and looking under. They're trying to figure out why is it not doing the thing the way it was expected to, et cetera.

These field operation people that are out there trying to understand what's going on, they may be up a ladder, they may be crawling into a space, et cetera. So, that really does force a different user experience. You can't just throw a desktop that's multi monitor display, and throw that on someone's phone and hope that they're going to be able to pinch and zoom and scroll around to find what they need to click on. They need to have a very methodical and very contextually aware ecosystem that is giving them just the time or the right information. Because if you're doing a maintenance or you're taking something offline that impacts production, all of a sudden, everybody's really, really interested in making sure that that experience is done efficiently. Every second that those machines are offline, that plant is losing money. So, that's a lot of those critical moments where you can't get things wrong. Obviously, we deal with some very hazardous environments where if you do things wrong, people can be injured or there can be environmental or other impacts. But I think that the principles are generally the same.

There's a lot of assumptions that go into a software that goes wrong. We just had a project recently where the project brief was very clear. We're definitely building this on an iPad. The iPad is the only screen that will be able to hold all of this data. Absolutely, I heard it like five times on the onboarding of this project. Okay. It sounds like it's likely iPad. I'm sure these guys have done due diligence. Let's just do a few user interviews. I think we had only managed to get about six user interviews. One of the questions was, how do you feel about an iPad interface? They said, "Well, frankly, with the gear that I have to carry to go do my job, if I have another big piece of hardware like an iPad in a protective case, I'm probably just going to leave it at my desk because I don't have room. It's heavy, et cetera, et cetera. So, if it's not on my phone, I won't use it."

These was assumptions done across the board with multiple vendors. We're all collaborating on this project that had already made a decision with zero validation from the field. In a matter of a couple of hours, we were able to find out that fundamentally all of the hundreds of thousands, if not millions of dollars, spent developing the state-of-the-art software would not be used because the end users don't have another set of hands to carry it. So, if they can make something that fits in their pocket, sure, they'll bring it along and will use it. That obviously changes the design requirements from, oh, we're just going to take our desktop screen and put that on an iPad, so it'll be a little smaller but not a big deal. Two, we need a mobile phone, form factor to build this software around. That's a complete reconceptualization of what that software is and how it works.

Luckily, we were able to find this out before it was built, and coincidentally probably saved them several million dollars in having to redo the UI. Because when they deploy it out in the field, all of the users would revolt and say, "I can't carry this. I don't have room for it." It's an interesting space. There's some simple fundamental user due diligence that I think can keep a lot of these things from going sideways.

Erik: That's an interesting example. Because I guess, on the one hand, you're doing business design, and you're working with a certain group of people on that in understanding the underlying business requirements and the model. Then on the other hand, you have the users. I guess, ideally, you would be engaging with the users first. I suppose this tool is somehow supposed to be helping them do their job better, so you would expect that they would be early engaged in the process and helping to steer not just the choice of user interface but also the functionality and et cetera.

How do you navigate these situations just as a service provider when you come into a situation where they say, okay, here's what we want to build? It sounds like, in this case, you were able to navigate but it was fortunate that you lined up those interviews early. Ideally, I guess those interviews would have been baked in before this company kind of—

Jared: They don't need data if they knew how to do this. Luckily, their lack of process is putting food on my table, I suppose. For us, ultimately, our aspiration is to apply scientific method to innovative or creative pursuits. When the client comes to us with a brief, we assume that from the boardroom, to the VPs, to the directors, to the managers who get funding to do these projects, that there are so many assumptions and biases baked in. "We've always done it this way. This is how we do things." We've heard all of this a million times. Maybe there's a vendor who plays golf with the right person. All of a sudden, we're going to work with this software because they're an industry player, et cetera.

We take that as the educated guess in the scientific method, where it's like, okay, this is a good place to start. This is not our end state. We refer to that as the initial framing of the problem statement. We then work with the stakeholders in a multiday workshop often. We'll map out what is the user journey. We'll identify the research plan, what are the business goals, technical limitations or enablers that we need to be aware of. Then all of a sudden, it's amazing just having everybody in the same room, whether it's virtual or physical. All of a sudden, the problem statement usually shifts around a little bit. It doesn't maybe change completely, but there's a refinement that goes on.

A lot of our goal is to help people not build things that don't need to be built, that won't get them that business value. We then go into a discovery program with our clients, usually in the effort to lock down a proof of concept or POC. That can be between 6 to 12 weeks or so depending on scale and logistics of getting the site and whatnot. In there, we will do the due diligence of really mapping out in granularity what is their process. Not what is their process that they think it is, but what is it actually on the ground, how do people actually work. A lot of times, from one site to another, with some of these larger companies, they'd acquire them. They have different cultures, different procedures, different org structures. There's a lot of legacy in these big companies. So, we map all of that out so that we can understand the landscape that these innovations are going to happen.

Then at the end of that, what we do is we'll give them a prioritized list of requirements that says, it's that 80% of your value is in this feature set. These other ones, yeah, if you have time and you just want to put some whistles and bells on it, great. But this is the stuff that will get you that return on your investment and will create the net percent value that you need to sell this to your higher ups. That's one of the key things that we deliver for them: it's the ability to get their projects funded. Because a lot of times, they may have algorithm, they may have gotten into Python, and they've got some ML stuff that they're playing around with, and they're seeing that this can be valuable, but they don't know how to make it into a product that will really, when the rubber hits the road, give them that value.

So, we map that all out for them in granularity. It's data-driven, totally defendable through observation and measurement. Then we'll also render out a concept of what this new product would look like. Of course, with design learning, I'm a big fan of our design team. It looks amazing. People get excited and go, okay — to sound very — here's the steak with a little sizzle on it, a bow on top. Let's get this funded. Then they can move on to building out the enterprise scale of that POC.

Sometimes we do the prototyping in code. Sometimes we just hand off at the design phase. A lot of times, we'll embed with their engineering team to make sure that their engineers are executing as designed — which is not a huge risk, but things just start veering off course if you leave it unattended. So, we usually have a partial designer that embeds with their team over the lifecycle of the product so that they're able to realize that why we're not implementing new sort of bugs or user friction points.

It's a lot of fun. We see these salty, old engineers in plants or wherever our job takes us. We see their faces light up, and they're like, "Oh, please build this software before I retire. I can't believe it's so easy. I've just been waiting for these two data points so that I can make decisions. Thank you." It's a really rewarding job. I love making rough people delighted, which is — I don't know — our career choice. But what can I say? We love it.

Erik: Well, bringing good design to enterprise software, that is certainly the God's work, right? But I'm curious about also the business side of this. If I think about my still somewhat limited experience in this sector, my instinct is that on the business case, there are extremes. On the value lever side, you have extremes of potential upside. If I'm thinking about predictive maintenance for an automotive manufacturer, they would say, "Well, okay. We've got a bunch of engineers on hand anyways. Things don't break down that often. If they do, somebody will walk over and fix it." But then, if you look at predictive maintenance on an offshore wind turbine, you're like, "Okay, well, then we've got to get somebody on a helicopter and get them out there." Or there's a magnitude more costly to solve. On the value lever side, in these extreme environments, you have a bigger potential value on at least in some cases around being able to solve problems using software data.

But then on the cost side, I suppose you also have a bigger lever in terms of risk. Okay. What is it really going to take in order for us to deploy a solution in an extreme environment where it's probably more complicated to understand all the variables that are going to contribute to the success or failure of the solution? I understand that you walked this through the POC process. Then you're not building the machine learning algorithms and so forth, as I understand. But it sounds like you are still quite involved upfront in terms of the business design. When you're dealing with very extreme environments where a variable prediction around what a variable might look like could be off by some significant value, how do you help to guide decisions? How do you evaluate risk and then therefore estimate ROI ranges in these types of environments?

Jared: A couple of things in there. The first thing I would say is it sounds — we don't have a huge amount of experience in manufacturing. I think we've touched the logistics side of it. But since the Industrial Revolution, manufacturing has done everything it could to automate and eliminate the human experience from manufacturing, the automation robots, et cetera. I think that our strength is really in — with humans, you can either augment them or eliminate them. Most companies are trying to do some combination of both of them. Ultimately, I think full automation is everyone's goal. But we're not there yet in most sectors.

Going to the ROI question, again, our mission is to eliminate assumptions. This is where the human factor's lens is very useful. We do an ethnographic study of these particular work environments. At the graphic meeting on site, hard hats and fire-retardant clothing or what have you, to go out into the field and actually measure how often are they making mistakes, how many meetings do they have, how many times do they forget tools and have to go back to the HQ or whatnot, how long does it take to walk from one side of the plant to the other, all of these things contribute. We produce very large spreadsheets.

For some of our clients, they may say, we don't know everything that can be innovated in this area. But we think there's a lot. We think that we have 1,000 people at this plant. We want to see if we can get to 500. If you can do that, that's tens of millions of dollars a year in potential savings. Where do we start? Do we do virtual reality training? Do we do drones for observations and tooling? Where do we start? That paralysis is a lot of what we're able to optimize.

We'll do what I like to call a managed innovation portfolio. This is where we will go out and do assessments across the organization, across multiple workgroups, et cetera. We do these calculations and create a prioritized chart, if you will, that maps against timeline, size of the opportunity and then ultimately, risk of deploying them. Doing a simple inventory checklist that saves people an hour a day or an hour a week doing their inventory versus doing drones and virtual environments, and all of this amazing but very costly and very questionable return things and takes multiple years to create.

We'll plot all of these against a chart and say, well, if you do maintenance and inventory and training application, and you can build all three of those in the next 18 months, you'll realize the same amount of money as you will with your fancy drone thing. But that may take you three years to build and deploy. The risk of your delivering it is extremely high, because you really have no experience with drones. That's something that we would recommend as a wait and see. Or, realize the return on the simple applications first, and then invest those returns towards these more moonshot ideas. That's one of the ways we do this. We come from a data-centric decision-making approach as opposed to, "Look, shiny object. Let's all go on after it."

Maybe blockchain is going to solve all of our problems. Maybe it'll be AI or quantum computing. Sure, I'm a big technologist and believer in the nature of human experience. But I think that without quantification, we can very quickly let emotions take the better of us. A lot of times, there's discussions at the boardroom or at the VP level that push down, I think, unrealistic expectations on people that are tasked with trying to uncover these things. So, we have a skillset that allows us to swim in those waters very efficiently, a culture that is very disciplined around what innovation makes sense and what doesn't. We're able to communicate that very effectively to our clients so that they can realize this.

Sometimes the projects are quite small. We have an application that needs some optimization. Other times, we want to figure out how to not shut down a plant. We need to save this amount of money in the next two years to save thousand people's jobs. How do we go about doing that and realizing those opportunities? The only way to manage something like that is to measure it properly. I think that the user-centric perspective with a bit of the business consulting muscle in there has proven to be, I think, quite effective.

Erik: It sounds like it's the right fit. There's another aspect which we haven't really touched on yet. But when you talk about risk, it brought this to mind, which is the topic of cybersecurity. Over the past three to five years, this has really emerged as a critical threat for energy infrastructure, and something that you certainly need to keep in mind as you start putting more touch points to infrastructure into people's mobile phones and laptops and IoT devices and so forth.

Do you have any particular expertise in that? How do you factor that into your decision making when the risk is not the risk, maybe the solution not being adopted or the ROI not being met, but the risk is some external actor attacking the solution?

Jared: Yeah, we participated. We're obviously not writing the code, which is usually the point of entry for a lot of hacking penetrations. There's also behavioral mapping. We didn't get to deploy this particular approach, but there was, I think, a lot of value in it. For example, there's a large pharmaceutical company. They were producing a low-cost country — they had all of their procedures on these iPads. It's a poor country, so a lot of people were ripping off these iPads. They didn't really care about the iPads because they were a few $100 each. But they have a billion dollars’ worth of research on them that was walking out the door.

We were exploring something as simple as like a beacon, like a geolocation with high amount of precision that was going to basically be in a permanently encrypted state, and only decrypt when in proximity to the machines that those particular procedures were going to be acted on.

I think that location is an interesting tool. I'm working on a white paper called the laws of context which touches on some of this. The built environment actually maps to a lot of our security and access control behaviors. For example, if you're at a cafe and you're on their Wi-Fi, and they have a bunch of smart lightbulbs, should you be able to turn the lights on and off? Well, I think most people would say, no. You can't just turn off the lights in the middle of a busy restaurant. But if you went behind the counter and you're near the manager's office, yeah, that would make sense that you're in that location and you would have access.

There seems to be some interesting structures from the human behavioral standpoint that you can build in a system that maps experience to the built environment, which adds that security layer as well. Having the proximity or, for example, movement or other behaviors, for example, your device goes south of the border, your access restrictions should be immediately shut off or your device flagged as potentially out of control of your employee or user.

There's a lot of ways that from the human behavior expectations that you can have things. You can get into wearables and whatnot and get into some fairly invasive ideas around. Are people making good decisions? Are they in a state when they should be? If there's access control to, let's say, control systems, should they be opening and closing pipeline valves in the middle of the night till the morning? Maybe if they're at the command center. Probably not if they're located in a bar or something like that.

There's a lot of different challenges around security. Humans clicking on email attachments or things like that, those are the human behavioral things that bypass all of the best technical cybersecurity out there. Obviously, training and whatnot play a big part of that, creating a culture of that. We have some of our clients that are actually moving away from connected devices entirely, interaction air gap in some systems due to the fact that cybersecurity has been unable to successfully bar entry into the system. It is a very volatile space. I think that some of what we are working on certainly can be a part of the cybersecurity landscape. But nothing is going to replace proper IT services in terms of just controlling and walking this down.

Erik: Well, it's certainly an arms race. Some of the concepts that you mentioned around location-based access and so forth, I think, are really worth looking further into for companies that have at least relatively standard processes for where people should be working. Obviously, not all environments allow that. Human behavior is messy, so you're always going to have edge cases where somebody is going to be pissed off because their access was taken away for some reason. But certainly, the human is typically the weak point in these systems.

Jared: It always has been.

Erik: Yeah, it always has been. We'll see if there's some point in the future when that's no longer the case, but it seems like at least for the foreseeable future.

Jared: Well, humans are good at some very simple things. I think Elon Musk, when he was racing to get the Model 3 production, realized that he could only get to 97% automation on the execution of — I don't have the exact numbers, so we have to look that up properly. But there was something as simple as, I think, wiping down the windshield. Or, it was a very simple task, but it was going to cost him half a billion dollars to build the robots to do something that he could pay someone $15 an hour, that humans can do very easily and that automation was going to be a significant impact and really no ROI in it.

Humans still have a role. I think that human intuition actually has some great capabilities. But there's a lot of fallacy in human experience, and biases, and things like that. I've seen it out in the field where people are telling you that they're really good at something, and then they're making errors right in front of you. I've also seen where if you trust only automation and sensors, huge problems.

I was at an oilfield. A guy went to the control system, and shut down the gas line to this one facility. Then he waved to me and said, "Come up here and listen to this." We put our ear next to the pipe. We could hear the gas just flowing at very high speed through the pipe. He said, "If I trusted the system, I'd be dead right now and so would you be."

It's one of those things where our sensors fail. Our automation has edge cases. Humans are really good at improvising in some of those spaces. At the same time, we've always done it this way. It creates problems that are hard to be as well in our culture. Well, sometimes very constructive can also be very constraining and all that. I think that that's as much as anything what we try to do. It's to bring a lens to this, so that organizations can understand really what they're doing well. Then with the areas that need improvement, help them frame the problem correctly so that they are solving the right problem.

This one particular use case, it was a secured area. They were searching vehicles going into the secured area. They were sure that the problem was the security officers were too slow searching the vehicles. So, they were hammering them with training all the time. The guys were very demoralized. They were holding up shipments into the plant. Everybody was yelling at them. It was a very tense environment.

When we went out there and measured it, we actually realized that these guys are within a percentage point or two of the absolute fastest possible time spent searching a vehicle. The problem that they had is that they would call and say — this was a place that only had landlines due to various reasons — that your shipment is ready. If somebody didn't answer the phone, the shipment would have to wait until that person call them. Other times, there'd be missing paperwork. Other times, people wouldn't be at their posts, et cetera. There'd be missing tags and things like that. It was almost every single problem except the problem they were trying to solve, which was people was actually physically opening trunks and looking under vehicles and things like that.

That is the kind of thing that I think organizations do all the time. It's that they create all this friction solving a problem right next to the root cause of what was happening. That's where fresh eyes and our approach to things, I think, can help them reach that itch that they've been trying to scratch for years, if not sometimes decades, depending on the organization.

Erik: It's a great example. It's incredible how a concept can live in an organization when it is basically spreading by word of mouth, by PPT, by know-how as opposed to getting a pair of eyes out on the situation and saying, well, let's actually figure out what's being done. Often, it's not done, right? Because it's nobody's job to do that until they hire you. It's kind of nobody in the organization who says, "It's my job today to go out there and watch and map out how things are done."

Jared, I think we've covered a good bit of territory here. But this is probably a sector where you could take a lot of rabbit holes down. Anything particularly interesting that we haven't touched on yet that you think it would be important or interesting for folks to know?

Jared: Well, I think just bringing this back to IoT and devices and sensor-related data, we have a fair amount of experience either from enclosure design or consuming data from various telemetries and whatnot. I think that the thing that maybe the IoT world needs to understand is that the flow of data from the edge to the user, there's a lot lost in that space.

The benefit of those devices is it has to fit within an organization that's able to adapt around those devices, and to make those useful, and get the return on the investment. I think that that is what we've seen time and again — these solar plants that are getting 200,000 data points off the field every minute, I think it was. But they still don't know what work they should be doing today, for example. That is the challenge and I think the opportunity with a lot of the hardware innovations in the IoT space. It's connecting that data with the business case, and then ultimately the user.

The technology, business, and user brought together in an orchestrated ecosystem is really powerful. If any one of those is off, the whole thing spins out of control pretty quickly. I guess, that would be my parting wisdom — that getting the sensors right is one of the steps, but that's not the end all of creating the value of your new technology.

Erik: That's a great point. I think a little bit of an analogue to maybe the late 1990s, early 2000s. We've invested a lot in the infrastructure. We now have the ability to move data around. Now it's time to actually make use of it, make a good software that people enjoy using and can really derive value from. I forgot. Last question. What is the best way for folks to get in touch with you or get in touch with your team more generally?

Jared: We've got a website. We've got LinkedIn. Feel free to email me at jared.huke@daitodesign.com. You'll throw that in the blurb somewhere on this podcast. I love to talk with you further. We take a very humble position, as I mentioned, so I'm always open for conversations and discussions even if there's no commercial aspect to it. I'd love to meet anyone who's interested in what we're talking about.

Erik: Well, Jared, thanks. I really appreciate you taking the time to speak with us today.

Jared: It was truly my pleasure. I'm excited about what you guys are doing. Thanks. Thank you very much for having me.