MacroFab Engineering Podcast #278
MacroFab's Misha Govshteyn and Chris Church check in with Parker and Stephen to give his take on supply chains, nearshoring and reshoring.
Design for Testing means enabling your product to be tested easier or quicker. But what about the documentation and implementation of the testing?
Chris Church returns to the podcast to discuss the recent outbreak of COVID-19 or Coronavirus in China and how it is impacting Electronics MFGing.
Parker is an Electrical Engineer with backgrounds in Embedded System Design and Digital Signal Processing. He got his start in 2005 by hacking Nintendo consoles into portable gaming units. The following year he designed and produced an Atari 2600 video mod to allow the Atari to display a crisp, RF fuzz free picture on newer TVs. Over a thousand Atari video mods where produced by Parker from 2006 to 2011 and the mod is still made by other enthusiasts in the Atari community.
In 2006, Parker enrolled at The University of Texas at Austin as a Petroleum Engineer. After realizing electronics was his passion he switched majors in 2007 to Electrical and Computer Engineering. Following his previous background in making the Atari 2600 video mod, Parker decided to take more board layout classes and circuit design classes. Other areas of study include robotics, microcontroller theory and design, FPGA development with VHDL and Verilog, and image and signal processing with DSPs. In 2010, Parker won a Ti sponsored Launchpad programming and design contest that was held by the IEEE CS chapter at the University. Parker graduated with a BS in Electrical and Computer Engineering in the Spring of 2012.
In the Summer of 2012, Parker was hired on as an Electrical Engineer at Dynamic Perception to design and prototype new electronic products. Here, Parker learned about full product development cycles and honed his board layout skills. Seeing the difficulties in managing operations and FCC/CE compliance testing, Parker thought there had to be a better way for small electronic companies to get their product out in customer's hands.
Parker also runs the blog, longhornengineer.com, where he posts his personal projects, technical guides, and appnotes about board layout design and components.
Stephen Kraig began his electronics career by building musical oriented circuits in 2003. Stephen is an avid guitar player and, in his down time, manufactures audio electronics including guitar amplifiers, pedals, and pro audio gear. Stephen graduated with a BS in Electrical Engineering from Texas A&M University.
Special thanks to whixr over at Tymkrs for the intro and outro!
Okay, welcome to the macro fab engineering podcasts. We are your guests, tip Wella and Chris church.
And we are your hosts Parker
Dolman and Steven Craig.
This is episode 278.
Ted Pola is all DMS chief ecosystem officer and head of next our Altium cloud business unit. Ted holds an MSc in engineering mechanics from Michigan State University, a BS in Oceania graph. Oceana graphic technology from Florida Institute of Technology and an MBA from IE Business School, Madrid, Spain. Chris church is the founder and the Chief Product Officer at macro fab. Chris has been working in the software industry for over 20 years with a focus on robotics and electronics over the last decade. Prior to macro fab, he founded dynamic perception and alert logic.
welcome Ted and Chris to the podcast. Oh, hoping y'all had a good day so far.
So far. So good. Thanks for having us. Yeah, absolutely.
Appreciate the opportunity.
So let's jump right into it. As some of our listeners might know, from our blog, and press release Altium was a participant in our most recent fundraising round. Can y'all expand on this? Ted and Chris?
Yeah, do you want to kick it off?
Sure, sure. So they, you know, we've been talking, you know, without him for quite some time. And LTM is, you know, we look at it amongst our user base, is one of the most prevalent EDA tools out there, and having the opportunity to partner up and team up with each other, with the two companies to really provide a better experience for engineers at macro fab and provide a better experience for engineers in altean. And the Altium 365. space, I think, was a really natural fit. And this is a great opportunity for both of us.
Yeah, just to add to that, I'd say LTM, likewise, has been paying attention to macro fab for quite a long time. And, you know, when we look at the electronics industry, and specifically, you know, how printed circuit boards and electronics are manufactured, you know, we think there's a lot of room for improvement. And when we think about something like digital transformation, it just seems like a place that's, that's ripe for that. And what we see in macro fab is a company that is dedicated to, really that that digital transformation, and, you know, we believe in that vision, and we want to support that vision. And likewise, you know, we're anxious to work together with macro fab to combine our forces into something that's really going to be impactful for, you know, for people who care about electronics.
So, given that digital transformation, what is all team's goals around connecting design engineers to manufacturing data?
Yeah, I guess the simplest way that I think about it, is that it's kind of like saying, you know, rather than doing something for someone, and on the to do I want to do something for you, or do I want to do something with you. And when I think about the way that we in the design world, we talk about manufacturing, you know, we always use this phrase, it says, designed for manufacturing, and it's still to me, deep down implies that you design and then you kind of like pass that along to somebody in manufacturing, when you design for them, we want to change that we want to change that to where it becomes designing with manufacturing. Because we inevitably see that people in the manufacturing world, they have something to say about design, so that it can be manufactured, more cost effectively, faster, more reliably, that sometimes people in the design side don't see because they're not connected to what happens downstream. And that and, and so fundamentally, that's what we want to do, we want to move it to a situation where design and manufacturing are integrally connected and are happening at the same time, not in a serial fashion.
I kind of envision somewhat of a Venn diagram where you have two circles that are separate, one is designed and one is manufacturing and they've traditionally not overlapped a whole lot or or you've you've traditionally paid somebody a lot of money, who knows how to make them overlap.
So they drew the circle. That's them in the middle.
Right. So So I guess this is bringing those two circles together, right?
Yeah, absolutely. Yep. That's, that's our goal. We want to we want to do that. And yeah, just make it so that those barriers, you know, we blur the lines between design and manufacturing, ultimately.
And I think you know, the really add on to that, that has always been, you know, one of the challenges we faced at macro fab. You know, if you go through all this great work to design a product, you've, you've done your research, you picked all the best parts, you spend, you know, perhaps a weeks or months on this circuit board design, and you upload it to us, and all of a sudden, we're telling you certain things, or we can't purchase them, this is going to cost you too much money. And that just that sense of frustration to go through all that effort, just to hear at the end, you really haven't hit your targets, if we can work together to really bring that information to the forefront during the design phase, and save that frustration get that get that design to production to manufacturing much faster, I think, will really have succeeded for for both of our customers here.
So what would the concept behind that is that taking is that informing the engineers into during the design process of the manufacturing process?
I think, you know, I guess from you know, within our team, we see that it's one thing to inform people, but it's a different thing to get them to work together. And I think that's more important. informing them is definitely important. But you know, the the industry's best sort of attempt at that so far has been treating design rules, for example, and that you have information, but it's not, it's really not the same as is people working together in the context of sort of looking at the same thing, right. And design rules can get you a fair ways. And they have, they've certainly helped the industry. But I think people working together people working in a more collaborative way, whether they're, you know, kind of focused on laying out a printed circuit board, whether they're focused on deciding which components are going to be put in it, or they're figuring out how the heck they're going to actually, you know, get that onto an assembly line and get put together. All of those things, you know, I feel and we feel as a company that, you know, those that that should be a collaborative approach, not not a rules based approach. Not so it takes more than just, you know, being informed it actually takes working together.
Perhaps I'm jumping the gun a little bit here, but in practice, how do you see that actually looking is that something where the as the design engineers physically clicking something on their screen, they get information about what they're doing, and the impact later on down the road?
So, you know, I guess I'll jump in again. And I would say that, I think that what we're, that would be kind of like, that would be the ultimate vision for what I think we can achieve together. Now, being practical, I think we can't go from where we are today, to that end state, kind of in one step that's going to take multiple steps together, or multiple steps to, you know, to get to that, to get to that place. But But yes, I mean, I think it when I think about what would be ideal, if I just throw aside what's practical and what you could do, I think it would be just amazing. If an engineer as he was designing, if somebody on in manufacturing or in procurement could say, Hold on, stop right there. Because you're about to design in a problem. Whether that problem is you're not going to be able to get this part, or more of that problem is this can't be manufactured on on on my line or with my equipment, or it's going to lead to, to maybe some, you know, signal integrity or crosstalk issues or something that you haven't considered. Absolutely, I think that would be the the ideal scenario. And certainly, we want to work towards that vision.
And that's, you know, really thinking from our perspective, as well. Imagine, you can do, you can design your board almost any way and it will mostly be manufacturable. But as you're making those design decisions, you're starting to really narrow down your success window, and who's able to effectively manufacture that product without issue. So imagine like as you're moving a BGA, to where another BGA is on the other side of the board. All of a sudden, you're getting feedback, hey, now you're requiring a nitrogen oven. Right now you're requiring epoxy, etc, these things, start giving you feedback, and they're driving your cost up this much. And then imagine if you could just sit there and say, Hey, okay, great. What's the best way for me to address this situation? And potentially have someone on the other end go, Hey, try doing this instead? Right? Try this strategy.
And I think I remember seeing some long ago in my career, some kind of statistic that I almost wouldn't want to be quoting because I inevitably get it wrong. But it was something to the effect that you know, 80% of your cost kind of is designed into the product in the first 20% of the time that you're working on that. And I think that's the moment that is exactly the moment where you have to have, you know, information at your fingertips that allow you to make better decisions on that. And I think, again, I mean, the key to that is that the people who often know that or not, it's not the designer, it's because that's not his job, it's not his job to source parts, it's not his job to figure out how he's going to manufacture that, but the people you know, that he relies upon, if they can contribute to that, then that sort of like critical 20% of the time upfront, can can really do wonders towards making sure you get design, right, first time you get it, you make it the most cost effectively, you kind of future proof it with respect to being able to get, you know, components, pair boards, etc, that you're going to need everything that you're going to need to be able to do that not only in kind of like a prototype context, but ultimately in production manufacturing, as well.
You know, I never really thought about that way. But yeah, you're right, the first 20% of your board design is finding what components you want, and choosing what packages they are. And that pretty much defines one your supply chain, and to your your manufacturability in terms of who you can use to assemble those parts, if you're choosing, you know, dip components and and through whole stuffs like Well, yeah, anyone can make that, but makes the board larger, but then you go swing it the other way and go, oh, I want to use Oh, one oh fives all my components, that's also going to drive up your costs for equally different reason.
Yeah, and I think that's one of the things you know, when we look at the paths of solutions, that that people have taken traditionally, whether it's, Hey, we're just going to do a bomb scrub down, we're going to do design rules, etc. What they're often missing in a lot of cases are the intent of the product, not just how is to be used, but the volume into which is being being produced, right? What is the warranty period on that product going to be? etc? What is the what is the price point you're going to sell it at? Taking in those kinds of intense earlier in the design process, and giving feedback? Where are you designing against the final intention? So I'll say for example, like you mentioned, using a lot of dead parts, you know, that's easy to do. But when you're starting to think about mass producing something, you're starting to kick off additional costs based on that intent of mass production. You know, if I'm going to produce 50, or 100 of these boards, it's going to get thrown on the Select assault or hand soldered somewhere. But if I want to produce 50,000 100,000, I'm now making you know, dozens if not hundreds of wave pallets, right. And this is driving up my Inari my engineering, and then of course, I now I have to have a facility that uses wave soldering. And you know, am I am I trying to mix chemistries here, etc, all these things have to start to come into play. And I think that by connecting the manufacturing intelligence directly to the design intelligence that LTM has, we have the first opportunity ahead of us to really start taking that intention and driving the design to a more manufacturable product.
Yeah, it's one thing that doesn't really get captured too much in when you get that EDA tool packet, all the Gerber's and Bill materials from the customer. One thing that's missing is, this is the biggest problem we have with like, part alternates, is they go okay, just give me a resistor, it's like, well, what's important about that resistor? Is it the value and the power rating? Or is it the package? Or is it? Can you change the package? And we can change the wattage rating and just tweak the value? Like what is the actual important things that matter for that component? So we can choose a proper alternate?
Yeah, and I think that's exactly why design rules kind of fall short. Because how do you convey that that's very sort of situational, right? And it's going to be different in every design. So there's no way that you can create some generic rule that says, This is always the right choice of a resistor. It's there's always sort of like if then, kind of, you know, logic that's involved in that that's in the head of the people who are involved, you know, across that sort of design to realization spectrum.
You know, I think I think what you said right there is is the kind of a key word. And something that gets me excited about this is it's locked in somebody's head somewhere. at every single level that we're talking about here. If you're talking about just finding parts or the guy who designs the boards, or the guy who makes 10 Or the guy who makes 50,000. There's different levels of knowledge that some apply across the board and some with them are just unique to each one of those I said, and if it's if there's something out there that can, I don't like using this word too much, but demystify all of those, or at least educate engineers about all of those rules, that's phenomenal. And then we don't have to, you know, peel everything out of somebody's head. Yeah.
And again, I think the key thing is that there's always going to be room for sort of specialization in the form of expert knowledge. And we know we value that a lot, and no one person is ever going to contain that all you know, in their, in their head, even if they did that probably the only human in the history of the planet who will ever have it. But but the reality is, they won't. So the key to that is enabling people to work together. And and, and I think the only way to do that is by virtue of digital platforms, which kind of just takes me back to the original point. That's what we believe in. And notice what we are trying to do in the world of design. And what we see macro fab doing in the world of manufacturing. So for me, this is just such a natural pairing to say that, you know, bringing these two very aligned philosophies together and saying, how do we make that whole thing work together better taking advantage of the cloud, taking advantage of a more intelligence, whether it's in manufacturing, its design, in supply chain, taking advantage of all the data that we produce, and we collect and yet, you know, and haven't yet been successful, and kind of putting it together and applying, you know, AI and ML to it, and so forth, that that's like a huge opportunity to really be disruptive in a really positive way for the industry. And that's, I know, from talking with, with Chris, and with Misha, macro fed CEO, and everybody kind of in in their respective teams. That's what we're excited about. That's the opportunity.
Yeah, and I think, you know, one of the things we we talk about there, and I think Misha wanted me to say something about DevOps in here, but too deep into that. But when we think about, you know, what it means to be a platform to be, you know, it's both in the case of like the design tool, being a platform, the manufacturing service, being a platform, it is about taking all of the components you really need along the journey, and being able to piece all those together into one into one coherent set to solve all the problems you have. So when we talk about that expert knowledge, you know, one of the big challenges we've seen historically with manufacturing is, you know, as you pointed out, there's the guy that makes 50, and the guy that makes 50,000. For you, right? A lot of times the information that's learned when they're making that first 50 Never translates over to the guy who's making the 50,000. And you have to relearn all of that. And that is, you know, a particular conversation that, you know, Ted and I've been having quite a bit about, which is how do we make that information available, all that design intent, all the stuff that was learned and figured out from the design phase, make that available all the way to the manufacturing? And then when you're coming back and doing a new rev on your product? How do you access all of that knowledge that was learned about your product, and the challenges and the fixes? And all that, from the manufacturing? Back up to the design engineer? How do we put all that together, and that's, that's really a critical piece, to a platform play like this is to take all those components, not only give you access to them, but retain the knowledge and the information, as you're working with those and as different parties are in there helping you out to build this product, putting it all together.
And I think, you know, just to kind of not to miss his sort of thinking regarding DevOps and how that relates to this, you know, I don't know that I would say it the same way that he would. But when I think about DevOps, I think about, you know, engineers in the software world, taking advantage of things like automation, collaboration, and then using those things so that you can move from kind of this this sort of like discrete product releases that happen every once in a while to continuous development and continuous deployment. And, and for me, that's an exact analog analog here to what we're saying is that, you know, we want to use knowledge so that we can can encapsulate it into into things that can be automated in the process that we're using. We want to take advantage of the fact that that knowledge comes from different places, and we want those people to collaborate so that we get better at what we're doing. And instead of having this sort of, again, this sort of serial situation where I live in my design world, and then one day, I throw it over the wall to Chris and he has to figure out what I meant, and where all that context was what was the design intent and all of that instead we can be continuously working towards creating one is going to be, you know, the, again, sort of like the product that's going to be designed right first time, it's going to be built right first time.
So this leads into this question it's only been already partially answered is, so do you envision that engineers will take a much bigger role in their electronics production with their companies?
I certainly do. And I think I think it's already happening. I mean, I think it's just, you know, I actually, like, when we look at the way that I think it's part of the reason why macro fab is becoming, you know, more and more successful is exactly that, as an engineer, engineers are, are taking already a bigger role in that. And, but but we've kind of, you know, with the technologies that we've got kind of given them to interact between design and manufacturing, you know, we've kind of we've kind of held them back, I mean, really, what have we given them, we've given them, you know, circa 1990s, tools, we've given them email, and we've given them phones, and now we've improved it, because we've given them a cell phone instead of, you know, a landline that they don't have to be locked to. But we haven't given them much more than that. So, you know, the emergence of a platform for manufacturing, and the emergence of platforms in the design world. And now the opportunity to connect them together. To me, this is, this is precisely because of that, because engineers want and need to play a much bigger role in production.
And I think, you know, to add on to that, to add a little bit, you talked earlier about the continuous integration and continuous deployment, one of the things that, you know, I background in software, you know, in addition to manufacturing, you know, really strikes me as the reason why so many of the cloud technology and tools out there are taken up so well is they give the right people the right level of control and information at the right time. So it's not like, you know, as an engineer, I have to tell you everything about how to build this product. But if I can, can, you know, when feedback comes in to change something, the ability to say, Okay, I'm going to take control over this change, I'm not going to rely on my supply chain team authorizing that park for you, I'm going to come in and authorize it. And I'm going to capture that back in the design here. So that the next time this happens, nobody has to ask me a question, right? You know, this is something I've answered it, the information is here in the system, it's ready to roll, and we're ready to go forward.
That's what engineers like to do, like, like to hear is not having to do things twice.
I, you know, I think we all live in the same boat, we hate having to repeat ourselves. And, you know, this was something that, and I know, you know, LTM has been developing around this as well, some some really great solutions there. But you know, one of the big challenges that we experienced in the past was that, that handoff to from the engineer to the purchasing team was often a zip file, right? They were static files that didn't change. And, you know, after a year or two in production, if they were trying to take that design somewhere else, what they're getting quoted to get built is not the thing they're actually shipping, right, so many changes have happened to that product on the manufacturing floor, etcetera. That a lot of it didn't even flow back to the engineer, they weren't even aware of those changes. And so it's like doing some Indiana Jones work, you know, with with every every new kickoff of production, you got to figure out all the stuff that is different from what this package says.
It's surprising how much that story has repeated itself. Having manufactured so many products over the years. You've given me PTSD.
I just, I just remember one time, like someone showed us a picture of the product, and I'm looking at the product online on their webpage. I'm like, these aren't the same products. Are you sure we're quoting the right thing here?
But usually what happens in that case is the procurement team is just using the original files they got quoted years ago, at their current cm.
Well, I think similar, kind of what what Ted said earlier, where, when you have a design package, and you hand it over, it's just files or a zip file or whatever, and half the time, it's just like the word good luck written on it, you know, and I think a lot of that stems from the classic business structure of what engineering looks like, like you have this team of engineers and just due to the communication structure, they build this giant communication wall around them, and they expect communication to come in one way and go out another way. And and the person Just think team, the way that documentation flows in between them. It's just it ends up being garbled when it when it's originally tried to be trying to be very structured and very strict in order to prevent issues. I completely agree with you, Chris, having engineers, perhaps have their tendrils a little bit further into other departments, it's actually a beneficial thing. I know, certainly, we ran into situations like that at one of my first jobs where documentation spawned from engineering. And it was great, because you had a very small select group of people who all had the same train of thought in terms of how documentation should look and how it should read and feel. But it seemed like the loop never got connected back, because it always spawned from one location. And so when there was problems, we just weren't told.
It was great documentation, right, for whatever the first thing
Well, kind of like go a step further and tell you that that, you know, on that idea of the role of engineering, and if engineers, you know, are going to be kind of like playing a bigger role in that I can tell you, you know, we've for four years now we've held a conference for our users and and that's called our team live. And at that conference, I can tell you that this topic of engineers wanting to know more about what happens in manufacturing, what they want to know the why behind how things where things go wrong, because they see it goes wrong, pretty much every time and I can tell you when and you guys will relate to this even more than than I will. But if I've gone to a fabricator or I've gone to contract manufacturer, I can ask him a simple question to say, how many times does that design come to you in a way that you can just send it out to the floor and get it manufactured? And the answer is zero, that never happens. And literally, they say zero in this sort of binary way. It's not, it happens once in a while. It never happens. There's always those sorts of questions and the end, what our users at those conferences tell us continuously is, yep, that's true. We agree. But we have no, we don't know why. And I think this kind of gets the heads down to that idea that they, you know, they need to take a bigger role in that they want to take a bigger role in it. And it's ironic to me in that I can remember, you know, decades ago, early in my career as kind of a mechanical engineer getting introduced to this concept of concurrent engineering. And, and this was literally 30 years ago, and yet, here we are today. So in kind of like, in a same in the same way, introducing a concept very similar and saying, right, design and manufacturing need to work together, design, manufacturing, and quality engineering need to be kind of on the same page and talking the same language and to kind of understand each other's worlds. And it's sort of like history repeating itself. Again, you know, kind of all over again, here. But I'd say that I can tell you for sure, that is the single sort of like most commonly asked question, by designers is, you know, why does that happen? And how can you, you know, how can you help us with that, and our answer up until now has been, you know, to really try to, to bring manufacturing people to the table to to be able to do things, like have a roundtable discussion on that, to try to help understand each other, but, but I think that the real, you know, the real sort of magic potion here that's going to solve the problem is to have them communicating with each other, you know, as they're, as they're making these kinds of decisions that, you know, maybe trade off decisions or whatever. But I just think that, that that's the answer there is that, that that intelligence have to come in, but it has to be in context of the specific design they're working on now. Because no design role will capture, you know, anywhere near all of the different scenarios that will come up. So I think it's, I think it's critical, and it's, it's not, I think this isn't like, you know, Chris, and Ted, or anybody from our team, sort of like dreaming this up and saying, wouldn't it be a wonderful world if it literally, you know, engineers and manufacturing people saying, we need your help to solve this problem, and we need it today?
Absolutely. And I think, you know, one of the things that we've really talked about, you know, one of the one of the key objectives in this partnership is really about enabling that communication flow, right? Whether it's, you know, whether you're talking about the macro fabs manufacturing engineering team making themselves that information available to the design engineer or the factory for you know, having the ability to give feedback in real time, to, you know, answer questions, hey, you know, I know you're already building this product for me. But if I were to change this, what impact is it going to have on you? Is it going to make it easier? Is it going to make it faster? Is it going to make it more expensive? Being able to get that feedback quickly and easily is critical to what we're working on here.
And one of the, I think, because Ted was talking about like, the last 30 years, and stuff hasn't really changed in that regards. I think what happens is, especially with these, what Stephen was talking about, like divisions of companies and like the like boxes, where no one wants, like, once information goes one direction, information never goes back the other direction, no matter what happens. And we've, I've experienced that all the time, especially with with, like, PCB fabricators, like the actual board houses. Where this is an example is you'll send your design files, and they'll just change stuff. And they'll even tell you, it says, like, I don't even like and they'll make it more manufacturable for them, but they won't tell you. So you can't update your design at all. And you just get the working files back sometimes, right? And then they're different. And you're like, why are these different? It's enabling that, that communication backwards and breaking down that barrier so that they can actually tell you, Hey, you should probably change these things. So we can don't have to change them later down the road or again, down the road.
Yeah, and I think there's another dimension to that too, as well. And I don't want to overly complicate the story. But maybe you don't want to take all those changes back in. Maybe those changes are too isolated to a specific process at a specific place. And you want to have that information in that awareness. But you don't necessarily want to apply that change globally. You know, I'll say for example, you know, one of the things that we deal with is every PCB fabricator, not every but PCB fabricators kind of fall into these sets based on the size of raw materials they they prefer to buy and work with. So you end up with different penalisation rules for different fabricators. Right? Now, that's not something you want to say everyone has to use this penalisation. Now, you might want to do that, really, if you're looking to do high volume production. But if you're doing a lot of iterations, a lot of changes, that's something you want to take in as guidance, but not necessarily, you know, sort of a hard and fast rule. And that's going to be you know, as we work forward, that's always going to be one of the challenges is really making not just information available, but again, that context and when it should be applied and how it should be applied, making that available to everyone in the process as well.
And something that might be a little more controlled for the engineer side, because that's more like the manufacturer cm, controlling the penalisation of the boards. But on the design side, the what how the paste is applied to the boards. There's two leading technologies out there, there's stencils squeegeeing, paste across the board. And then there's also jet printers, both work in a completely different manner of how they apply paste, and enable you to do completely different things with with components on the board. Whereas the pace the pace jetter, you can, you can put large, large components like the have large thermal pads and that kind of stuff near other components that don't need a lot of pace, because it can selectively deposit the part of the piece on the boards. Whereas a stencil, the only way to do that is with a step stencil, which, besides the NRA cost also has other issues of like, when the blade goes across the steps Central, it's going to leave a shadow area as it goes across the step that causes all sorts of issues. So you might have two different paste files, depending on where what contract manufacturer or in terms of Acrab even at our HQ factory, it it can be paced on the jet printer or in the stencil as well. So it depends on the volume. And that kind of and those considerations.
Like Chris said, That's all part of the context, right that you need to know that it's not only it's not only, you know, I wanted this resistor, this capacitor in this location, but it is, you know, is this going to be a product that is it's going to be, you know, I'm going to make 100 off and that's that's it, or is this something that I'm going to make, you know, a half a million of and those are different things. And likewise, you'd say well, what's the what are the operating conditions of the end product and make it something that's going to be like for, you know, ruggedized military use or is it is something that sits inside of somebody's, you know, inside of a cabinet in somebody's house and hidden away, and, you know, the note never faces any, you know, difficult conditions or anything like that all of that kind of like contributes to that, that idea of context and needing to know, you know, what was the design intent? And what is the, what's the production intent? What's the what's sort of the customer intent, all of that stuff needs to be, you know, understood to make the right kind of decisions. And, you know, the other thing I think about a lot is that the, the, you know, the reality is, is that people in the, in the manufacturing space, they have a set of tools that they use, and it can be cam tools, it can be pre cam tools, there's engineering tools, there's all kinds of things that they use, when they get that packet that zip file, which by the way, I think we should, we should endeavor to do away with that entirely, because that's, it's just sort of like introducing error into the system that ultimately, I don't think that we need. And that's another thing that I think that we do together. But, and on the same. By the same token, we have all kinds of tools in design. And I think we can't try to convince people that either of them should switch tools, or that we're going to find one universal tool that that does it all, I don't really think that's feasible. And I think the, I guess, I would say that sort of core to what our team is trying to do now with with our cloud platform, you know, in our users see that through features and functions and so forth. But we're trying to make that cloud platform now, we're opening that up. And you know, you use the you even, as you introduce me said head of Next, our Allianz cloud business unit, well, next hour is just, you know, the partner facing side of that same cloud platform, we call it LTM 365. For our customers or users, we call it an XR for partners. And that's like opening up API's data streams, and and embeddable kind of experiences that, that allow those tools to be able to communicate with one another seamlessly. user shouldn't have to worry about that. But imagine that if you are, you know, in one of macro Feds factories, and you're using whatever, fab 3000. And imagine rather, at the point, when you see that there's an issue with that design. Rather than taking that out of the tool and putting it into an excel sheet, or a Word document or an email or something that you can simply comment on it right there and have all of a sudden, without even thinking about it, the guy on the design side of the equation is seeing that reflected in Altium. Designer, right, that's the kind of thing that I think that we've really got to look to, to do is to not try to ask people to change, but to try to make the things that they are already doing work better and work more seamlessly and, and do that in a way where they don't have to think about it, it just
works. less friction in reporting the problem,
exactly, less less friction, and all of these aspects of of, you know, ultimately, this is a collaboration problem. I say a collaboration problem.
No, that's 100% what it is, yeah,
it's not that people don't collaborate, they do we collaborate every single day, but we just do it in a really poor way. So this, the, there's no excuse for us not to be able to use the technology that we have today and 2021 to make that, you know, work seamlessly, like as if we were, you know, constantly connected. And, you know, through headsets and talking to each other and seeing the same thing. That's that's the world that we should be that we should be creating for. For the electronics industry.
I think I'm gonna jump in and ask a question here. I know, it's normally different for supposed to answer questions. But, you know,
this is just a discussion.
Yeah, so discussion, we were we're communicating information in bidirectionally through our podcasting platform here. But, you know, one of the things, you know, we talk about, you know, sharing information, but there is when we talk about collaboration so far, you know, we've been really discussing people doing independent things, right, and putting their results and that information in there. But But Ted, what's your take on true collaboration in real time, through platforms like LTM, 365, next door and macro fab, like sort of like an MPI process? You know, if you would
imagine? Yeah, no, I mean, I think I think I think this is exactly the future and the future as we envision it. Even if we didn't envision it, I think it's inevitable, that's good that it's, it's going to happen, right? There's just momentum, the slope of the ground is going in that way. When I think about new products, Introduction, I think about the idea that of making decisions. I mean, ultimately, for me, you know, new product introduction is sort of all about that it's making those decisions about what products do I want to introduce? Is there going to be a product market fit for that? Can I produce it at a price point that's going to actually be successful in the market? And, and in order to do that, I think, you know, two things, at least, probably many things, but at least two things that I think don't happen today have to happen. One is that we have to have you make decisions, hopefully, based on information, right, rather than based on your gut feeling, I think this thing is going to be successful. You everyone would like to do that based on having, you know, not just data but intelligence. Right. And so I think I think the opposite one, one thing right now is that I know on the manufacturing floor, you guys are collecting all kinds of data. Right? And I think that and likewise, on the design side, if I think about, you know, LTM 365, and this cloud platform, and I think about octopod are such a search engine, that we have to find electronic components and so forth. There's a tremendous amount of information in all three of those worlds, or all three of those domains about what are the kinds of chips components, whether they're passive active, whatever, what what, what things are people interested in, what are they looking at, but then we can say, why because we know the kinds of designs that are being produced? Are these more high speed, high density designs? Are they using, you know, different newer forms of interconnect to that sort of things? And we also know, likewise, you know, we can see what's happening from the side of, of production? And how, you know, is that is that effective? What, and, you know, what things are being used in what kinds of quantities where in the world are they being produced? And, you know, there's a lot of just a tremendous amount of data that exists that that could be used to help us to make those decisions. But it's really hard to sort of, like, harness that and do something with it. And so when I think about, again, this new product introduction, and, and, you know, how is this going to how was how our digital platforms are going to play a role in that? Well, I think, I think it's inevitable that that will happen. Because everyone, everyone that I know, every one of our customers that I work with, are asking how do you How could you help us to make those decisions more effectively? It's not just now about saying, you know, how can I like, sort of like speed up the design process? I think we're, in many ways, we're sort of like past that era, where we kind of like looked at sort of, like gross improvement areas, and we're down now to where, you know, we in order to kind of take the next steps and being able to produce things more, more efficiently, faster, more economically, all of that kind of stuff. It really comes down to intelligence and digital platforms, I think is the only way that we're going to harness all of that information. It's the only way we can capture it, is it manufacturing floor today? It let's be realistic, it is on a digital platform, in terms of collecting information in some way, but we didn't ever connect it things like, you know, how do I quote those jobs? How do I make sure that, you know, again, that connection between the design files coming in, and the things that we need to work with here in the manufacturing plant? You know, how do I make sure that they're the same thing? How do I make sure that I understood the intent, all of that kind of stuff? Right, so I, I don't even see it as a question. It is absolutely a matter of when not if. And I think, you know, it's our intention. And I know, macro fabs intention and our intention together that we're going to, that we want to be first, then we want to introduce that and, you know, for the benefit of our, of our customers, you know, and for our companies.
And I just want to want to jump out there one thing because I'm like, you know, thinking through this, and I'm like, I've got this wish in my head, right? You guys have this really cool viewer, where you can take where remotely two people can be sitting, you know, across the country from each other. And you can, you know, look at the board and 3d 3d view, 2d view, bring up the netlist, et cetera. Now, you know, in my world, you know, these days, MPI mostly means like, Oh, we've already designed it. Now, you figure out how to manufacture it. Good luck, right? And I'm imagining that kind of MPI meeting, right, where instead of sitting here with printouts and documents and people are on video calls, we can actually take the design, look at it, and see aren't bringing that information in real time, like see this here, this part, it's the problem, because we're getting feedback in real time from the same these, these components are too close to each other. And now you're going to have this issue. Let's go ahead and just move that now, right now and have that reflected back to the design, update the manufacturing instructions. And imagine doing that through a platform where every aspect of that process and I'm, I'm even stepping a bit further here, because this is really aligned with a lot of the stuff, you know, I've been having to work on recently, which is, now imagine that fitting into an enclosure, right and in the process and everything, a real product coming together, the being able to sit there in a world and say, Okay, we're all looking at this, you see right there, that radius on that, that screw boss in that half of that enclosure, is going to have an interference problem, about 40% of the time because your tolerances are here, and we can see this, and then actually start making changes in real time. So it's not just about controlling the flow and the intent, but it's really about true collaboration between all the parties there.
Yeah. And I think the critical thing that you said, Chris, in my mind is real time, because again, that collaboration it takes place, but super inefficiently. I remember very distinctly talking to an engineer from Google, who said, you know, why is it that, you know, I have to zip up a set of files, and I send that to my fabricator or my contract manufacturer, and he finds something like that, that needs to be adjusted. But he happens to be in another timezone. He might be across the world. And, and he might be even speaking a different language. So what he will do is see that problem, and inevitably, there's a 24 hour turnaround because of the timezone before the answer comes back to me. But I don't quite understand if I'm, if I'm answering the right question, because I don't have the context. I've only got the written word or something that's in an Excel sheet. So I have to turn around and ask him to clarify that another 24 hour passes. And then maybe I've maybe then I understood what he wanted, I can make that change. And now I send those files back to him again and wait for a confirmation days and weeks pass while this stuff happened. And literally this guy was like, say tearing his hair out. I've obviously done that a lot. But but but literally saying why why is why does it have to be that way, there's got to be a better way. And this is the better way real time collaboration.
It's not just that, though, is because you were talking about how poor we collaborate now. And the reason why it's poor, is because it happens after the bad things have already happened. If we could collaborate in a way that would make it so we can get ahead of those than the collaboration is just better, and everyone's in a better mood. And maybe people will actually start liking meetings again.
We'll also if the collaboration is informed by the wealth of data from both LTM and macro fab that helps guide towards the correct answer or one correct answer in those meetings, such that you don't just beat your head on the table looking for answers.
I think, you know, to kind of double down on that for one more moment, you know, there's always get the statement wrong. But there's like this old management thing that your organization structure tends to replicate the communication style within the organization. And we look at the problems we have today. And especially around collaboration. It is because all the tools at each point in the process that everybody's running are really running in silos. So it's not that you do a collaborative MPI process with your contract manufacturer. No, no, you send them your files, they perform the there NPI process with their tools, they produce the report, they come back to you at the end of it. Right. There's, it's with the existing toolset and the existing way that we have implemented these processes today. I mean, as an industry as a whole, you really get can only get a sequential sequential process out of that, to get it collaborative, we really need to get the tools talking to each other in real time, so that the engineer can be the manufacturing engineer can be sitting there with his tool that he's comfortable with. But you're getting it instantaneously instead of having to wait for him to produce a report at the end of it.
Yeah, and I I actually fully agree with what you said, and maybe to put a practical spin on what we're talking about. I mean, we've talked a lot about the concepts of making these things work together. But if I could just be really practical for a moment. I think, Chris, you hit on exactly kind of where we're going together in the sense that you know, right now, what, you know, again, somebody finishes up at Disney And Altium Designer and they create a release package. And now that release package is sitting there on his desktop, and now what happens to it, he's got to go to something else like email and independently again, just sort of like, toss it out into space and it gets there. But there's, but there's no, there's no connectivity, and really what we've been talking about, and what we're going to do is to make it such that, that that, that tool chain actually becomes a connected set of links, because I think right now, there's many breaks in the links of the tool chain, if you will, that exists when you go from design all the way through to realization, which is my word for manufacturing, right. So I think, you know, what we're going to do together is make it possible for the design engineer, when he says, you know, release to manufacturing, it is literally doing that, because those tools are connected, and when he presses released to manufacturing, it can go from Altium, designer, to, to tooth, it could be you know, fab 3000 Or it could be a you Camco tool, or it could be a frontline tool, or whatever it is on the other end of that, to make those things connected, so that the links are literally connected together, that's what we're going to do, right, so there isn't going to be this intermediary of, you know, having to wait for an email or a phone call or, or, you know, worse yet, sometimes, you know, a package in the mail. It's, we're gonna make it such that the design engineer, first of all, you know, that that sort of real time collaboration that Chris talked about that that exists that as he's making decisions, if he wants to invite a manufacturing partner to look at what he's doing, and to help provide some insight into what his decisions mean, downstream, he's going to be able to do that. And he's going to be able to do that tool to tool, not, not through some sort of intermediate step that really doesn't need to be there. That's what we're going to do together, we're going to make this streamlined, seamless sort of flow of information, of data of design information of manufacturing information, and, and just sort of improve that whole, that whole process to be real time.
And I'm, and I'm really excited about this, because, you know, in our world, the design has always been upstream, there's a, an upstream silo that spits a bunch of stuff at us that we may or may not be able to interpret, we may or may not understand. And there's there's not to this point, there hasn't been a ready and willing partner, to engage with us to create that communication flow. And, you know, having that will result in better outcomes for, you know, the design engineers, the purchasing teams, everybody that will really have a measurable impact on the productivity and success of those those teams out there.
Yeah, and I think it's a mandate from from, you know, for our industry, you know, you can everybody can read the same sort of information on how much our industry is growing. And, you know, it wasn't too long ago, I think it was on like, 2018, we said, there was something like, I don't know, 17 17 billion connected devices, connected devices, or something like that in the world. And, you know, now By most estimates, it's going to be in five years time, that's going to be 100 billion of those devices. And the reality is, our industry can't, couldn't even meet that demand today, and because of the issues, exactly the issues that we're talking about. So I think, you know, what this is going to do is enable us to work together to, to be able to, to achieve that. And, and, you know, not to be to sort of philosophical about it, but you know, I think it matters, because when I think about what those you know, devices are, you know, these are, these are things that people rely upon every day. I mean, we've had users of our software show up at our conference and talk about the fact that they are able to design a cochlear implant that helps somebody who is deaf to be able to hear for the first time in their life, that helps somebody who who is a paraplegic to be able to actually you know, manipulate things around them into interact with their world physically, again, which they've you know, kind of lost that ability to, to help you know, in the healthcare industry so that we can, you know, better diagnose and treat diseases and everything. Like I said, I don't want to get to sort of philosophy philosophical about it, but I think it's important to realize that this isn't just about two companies talking about how do we make more money. It mean, it hopefully results in in sort of like enlarging the potential pie for everybody. In our industry, because we are able to produce the, you know, or meet that, that growing demand for that stuff help our customers to actually deliver more innovation. And, and, you know, hopefully make an impact on society at the same time. So, you know, I, I think it's both exciting from a technical perspective. And I know that's where Chris, and I'll get excited because we say, Oh, can you imagine a future where we can make manufacturing and design work together? And that's super important, but I don't want to lose sight of that big picture that we, you know, this, this, it matters that we actually do this.
So I got I got a quick question here. Actually, it might be a little too early, since Altium, and macro have just started working together. But for what can all teams and maxpreps current customers expect to see in the near future with this collaboration? Well, you know, what's the first impacts that they're gonna start seeing?
Well, obviously, we're not, we're not ready yet to come out with all the details, this, there's going to be a whole lot coming from us in the near future here. But I think in general, I can speak in very high level terms. Because these are, these are still going to be impactful things is, on one hand, from the macro fan perspective, you are going to see better intake of information from Altium, and other EDA tools, because our team has actually done a lot of work there. And we're really understanding how to interpret this data and find find useful information in there. And, you know, being able to leverage outcomes experience, especially dealing with outcome data, right? To get a better smoother experience for the engineer on that intake of that design information. That's going to be a big part of what they're going to see. And likewise, you know, as we mentioned earlier, being able to take the data that macro fab has about, you know, cost constraints about process constraints, and take that all the way up to the design stage. That is really the two of the key areas we're focusing in on right now.
Yeah, and I'll go a little bit further and say that, you know, the, it relates back to a question you asked earlier about, you know, the role of kind of, you know, platforms in new product introduction and things like that. And I think, you know, one of the things like if I think about, again, sort of the way things are done today is that engineers, their ability to participate in sort of the sourcing process to, you know, to manufacturers is a little bit sort of hampered right, because they rely on other people many times in their organization in purchasing and procurement to help make those decisions. And a purchasing and procurement person, their context is often limited to like pricing, and timing. But the engineer knows a whole lot more about intent. So I think what this is going to enable is for the engineers on the design side, to be able to participate in that those sourcing decisions and those sourcing conversations that will result in those decisions with manufacturers and do that in a way that sort of everybody wins, because better those those decisions are going to be are going to be better and at the same time invite their, their manufacturing partners into the process. While they're, you know, at the point they are making those design decisions. And, and we will I'm not going to put, you know, a name on it, like it was a product name or something. But I think making that possible is what our customers should expect from us. And they should expect that from us not on a time horizon. That's, you know, so far out in the future that, you know, it's interesting, but it's not impactful. We're striving to do this in a hurry. And it may be that we don't have kind of what we envision as the ultimate 100% solution, you know, on day one, but I think that we will, and I know Chris, Chris, myself, Misha, others who are all committed kind of committed to saying, let's, you know, let us let's put this on a rail, it's fast track it so that we can get something out there that that starts to give users some of that capability. And then when I say users, I mean, sort of, I mean, customers on both sides of what is you know, that those sort of walled gardens today and make it you know, one big playground where they're all playing together?
Absolutely. And I think, you know, Ted, you hit on a good point, because if we look at that future vision that requires a lot of people, a lot of companies out there putting in effort. And if we start out with that perfect vision and say it has to be that to come out, it never actually comes out, right? Because it's that momentum of one success after another that incremental gain that really, you know, encourages other people to come into the party. So our our first step here will be to show immediate value to LTM users into macro fab users through this collaboration, and we hope to have very quickly, some things everybody can now do that they couldn't do before.
Yeah, and we'll learn from that, right? I mean, it's the the customers who engage on that I'm sure they're gonna, they're gonna come up with ideas and requests that we may not have considered yet, right? And we're gonna look at those. And we're gonna say, That's a great one, let's let's actually, you know, work to put that in. So I think it's an important, you know, the partnership is also with our customers. It's not just the two of us. So we've got, you know, that when I say to us, I mean, macro fab and LTM. It's, it's more than that. It's all the customers of our respective companies as well. And, you know, I think, again, if people should, I mean, they should expect that we're going to start to deliver against that vision, you know, as quickly as possible. And I know that there are things that we have identified as the kind of low hanging fruit, if you will, that we can do relatively quickly and relatively easily. And then there's sums that some of them that are going to require a much bigger engineering effort. But, but we will, we will take it on and we will, you know, knock those out, step by step. And we'll make that sort of connected collaborative vision a reality.
So we could expect a future podcast in those plans.
Definitely a future podcast.
Yes. Absolutely. And hopefully, we'll have kind of the, you know, some some of our customers on there talking about how it's been beneficial for them, how it's helped them and why they think it's important as well. Oh, that'd be great.
And I'll get to be a little less cagey. Because we'll we'll have, you know, probably a an actual feature release out there. I can talk in great detail on.
Yeah, the real nuts and bolts
Well, thank you, Ted, and Chris, for joining us on the podcast to share and explain this, this announcement to us.
Absolutely. Absolutely. I really enjoyed. I always enjoy talking with you guys. So
yeah, and I appreciate the opportunity to talk to you guys for the first time, so hopefully, it won't be the last.
So Ted, you opened for us. So Chris, you get to close this out.
Awesome. Well, that was the back of five engineering podcast. We were your guest Chris church and Ted Pallone.
And we're your host Parker Dolman. Steven Craig. Later everyone take it easy. Thank you, yes, you our listener for downloading our podcasts and sticking with us in our live stream. If you have a cool idea, project or topic, let Stephen and I know Tweet us at McWrap at Longhorn engineer or at analog EMG, or emails that podcast at Mac fab.com. Also check out our Slack channel, you can find it at Mac fab.com/slack. So after I stopped the recording, Steven kept talking and he dropped a question that he was a little too polite to ask during the actual recording. I managed to piece together the audio from various sources. The quality is not the best. But I want you to hear what happened next.
I actually I've got a little bit of a, perhaps a pessimistic question to ask. So with all of this integration and collaboration, it seems like there's, you know, you were talking about all the links that need to be made between tools in between people. And that seems fairly monumental, and in terms of scale, quite, quite large. And that seems like a lot of things that could break. Email, we kind of dogged it in a way. But email is great, because it's universal, right? It's just communication. What what what are your concerns about, you know, something potentially breaking and then the whole system, the whole line is broken.
From my perspective, good architecture prevents that from happening, right? You, you have to take into account. Not all the possible things that could go wrong, but the critical things that can go wrong, and you build the systems in such a way that they can self heal around one of those problems. And yeah, I know I'm speaking a little abstractly here. But let's let's get concrete for a moment, right? We deal with this in networking, for example, right? The idea that, you know, this packet of information is very critical, right? And I need to know that it got there. So we build a pro We'll call around that that says, hey, you're gonna do this triple senac. Right? In TCP, for example. And that was a thing that was added on as a safeguard around the existing protocol. Because you know, the experience of, you know, we're going from the small controlled network to a larger one. So, from a general perspective, right? That those sorts of things, right, there's no reason why what we're building should fall apart if one link in that chain isn't working, what you'll lose those feedback from that link.
Yeah, the other thing I would say is that those protocols that you're talking about, Chris, I mean, note that I mean, when you think about it, email uses the same protocols, and it has the same vulnerabilities. So I don't think that there's anything fundamentally different about about what we're trying to do with this. Yeah, there are. So you may think that you made suggests that there's more endpoints, but I can't imagine having more endpoints than email. So, you know, I don't think that this is really any more fragile than that is other than, you know, I mean, the, if everybody follows the protocols, then, you know, there shouldn't be really, you know, kind of a terrible issue.
I actually give a TED, my view on it is, it's already broken, really bad. And so anything that you could do to improve it, it's gonna be super beneficial. I didn't get to say it on the podcast recorded, but like, because Ted was talking about zipping up your files and sending that over there. And that's kind of like, I've talked to engineers before. And that's their way of versioning control. I've actually zipped up the wrong file so many times in my life. It does not fix the problem.
We've solved that in software development, right? I don't have to have anyone at this point. Any human being touch any file to deploy our software? Right? Literally, they're checking it into a version control system. It's going through automated testing, right? It's building it, it's testing it out. And when that's approved, it's pushing itself out to the servers, the servers, not even running servers anymore. It's just tearing down whole sections of the cloud environment and rebuilding them on the fly.
It's not as perfect church, because we do know that regression is a thing. Yeah.
We're not gonna we're not gonna talk about the regression. But imagine,
imagine trying to do that, you know, again, sort of
a better way to do it.
For sure. That's, that's impossible. Right? So I think I think there's always going to be no, I mean, there's going to be no perfect system that that is also sort of like unobtainium, but I do think that we have a good shot at this, especially if we can kind of like agree on it. At the end of the day, there needs to be sort of like certain representations of a design, that that are sort of like the design, it's the information of record. Right. And and those things have to be agreed upon, there's going to be, you know, something like that, that multiple sort of instances of that, that exist in the in the manufacturing world and some that exists in the design world. If those are vision controlled in the right, revisions are connected together, then it should, you know, it should make a lot of that work. But But ultimately, I think this is it's like, it's like sort of arguing about the cloud and saying, Well, we're not ready to go to the cloud, because it's not secure. Well, I can guarantee every one of them skimmers, and I could prove it to them that that they are far more secure, working in the cloud, than they are working on their desktops and sending files around through through unsecure protocols, or worse yet, through, you know, USB sticks and things like that. So far worse situation than working on the cloud, at least on the cloud. We can also see, we don't have to, you know, there's no record of who's stuck a USB stick into my computer. But there is a record every time somebody touches something in my version control system. That's
whether it's good or whatever. Yeah, it's one of those statements is like, well, I don't trust AWS security. Well, let's compare the size funding and experience of your I, you know, network security team versus Amazon's. And then let's figure out which one here we want to rely on.
Yeah, plus, you know, the other thing is just, again, we got to take some baby steps, right? So I think, yes, we kind of lay out this whole, you know, comprehensive vision for a perfect world. And the reality is, we'll probably never even achieve that. But if we just connect a couple of things together, it's going to be far better than we've ever had it before.
Yeah, I think I think it's I think it's fantastic. I'm super excited about it. I just, I guess my my concern my Like be something that might not just be my own, you might run into that a bit. Somebody's asking how do all these get connected? And if anything breaks, does all of it break? And of course, you design that into the your process. But I expect you'll be asked that,
because I guarantee it. Because you because you brought up email and that example, Steven. I've done it a lot where I'll like, like, just wake up and look at my email. And then I'll just like, click it, read it. And then like, I hit my snooze button fall back asleep for 10 minutes. That means is gone from my brain has been marked as read.
Email is superior, and is inherently human that is flawed. Yeah. So
so whenever someone brings up email, I'm like, That is the worst way to communicate with, especially me. I'm like the worst with email.
Yeah. But my point is, it's universal. Every everyone expects it, everyone knows it. And it's something that you can fall back on?
Well, here's, here's sort of the beautiful thing about that. The beautiful thing about a universal tool with major flaws, is it's waiting to be an interface to a much more controlled tool. And so for example, you know, we use email coming out of the platform to indicate something has happened. But the action you take off of that is back on the platform. So the answer of did someone read that email? And then hit their snooze button? Well, we'll know that. Right? You know, for example, because I can see, well, not always, but many times, I can actually see that you've opened the email, right, our software can see that, we can see that you didn't click on the action. And that can in itself trigger a whole new set of events, right, that can bring into someone's attention, hey, this is a critical item. And they they've read it, but they haven't responded in an hour. Let's go and push another notification to them that, hey, remind you you need to respond to this.
You know, what's your
right to bring it up? Because people will ask it for sure. Yeah,
I think one of the one of the biggest things that really resonates with me about that is our about the whole platform that you're talking about there, or connectivity of it is the fact that feedback occurs in one location, as opposed to being distributed among many people's emails to be forgotten. If it is something that is in your face, and has some kind of action tied to it, or if the platform just continually reminds you about this action, that is immensely helpful refer revisioning.
Yeah, and that's, you know, that's one thing, you know, especially now that we're not not broadcasting the podcast, we're able to look at how people are using the platform itself, and actually construct dynamic content and information to make them more successful, based off of exactly what they're doing. And it's not exactly real time, but it's pretty darn close. You know, for example, we know if you've made it to a certain point in the process, and we can send you certain types of help. That's the kind of things you can start doing. When you get all these different components and individuals and companies working together in a platform like this, you can actually start automatically identifying, hey, these guys actually need tooling help, right? And then can we go out and, you know, with without even having to make them realize they need that help? start presenting it to them in real time, hey, you know, click here to get help with this, click here to get help with that. That I think is really, for me, that's one of the great promises of the current state of technology is it's not just about the features and functionality, but how we take the information from how people are using those features and that functionality to really kind of reconstruct their interface or their experience on the fly.
Yeah, and there's examples of that sort of all over the place in in sort of, like analogues in the consumer world, like think about something like as simple as like a shopping cart like if I go and I look at something online, and then I you know, I might put something in the shopping cart or maybe even just look at it, but then I leave the site in and you know, often I'll get an email back and says, Hey, you left something in your cart. Right? Did you want to buy that or or think about it like recommender engines and recommendation engines that say well, other people who have done things like this also looked at and I think we have that opportunity we could say other people who Whoo hoo worked on, you know, designs like this ran into troubles like that, right? And would you like help with that? Or would you'd like to talk to an expert or something, you know, something, something along those lines, I think there's those, you can see the future, I think you can see the future when you look at those sort of like more simple kinds of environments in the consumer space. And now think about how we kind of apply those concepts in in our more complex world, but I think they're equally applicable.
And one of the big things I think about getting feedback for is, a lot of times you start doing like, you start changing your design for manufacturability, by just seeing what kind of RMAs you're doing. Like what you will say, if I'm a company, I'm getting my product from, from macro fab, and I see a problem. I'll change my design based on that. But that's not, that's probably half the things, right. There's a whole thing that the QA team is doing, right? Being able to capture that feedback, too. And pass that on to the engineers, so they can change even further change your design and make it easier to manufacture is something that would be met, like, that'd be just game changing.
Man, you're you are hitting on. One of the things I love the most about the potential future here, right, is, you know, and again, this is something I've been living in for a while. So I get to, I get to have nice, wonderful dreams about what it could be. But imagine, like, you know, one of the biggest challenges for me back when we were running, you know, say dynamic perception is what impact did that product change, have on the profitability, the quality, etc, of this product, and be able to in real time, see the data coming off of the floor as you after you've made a design change, and be able to tie that to that design change and say, that has resulted in a 5% Lower Fallout rate, or worse, you know, a 20% Higher Fallout rate, right, you know, lower yield, because of that change. And to get that back, you know, as an engineer, while your manufacturing is going on, not three weeks after the run completed, and somebody printed out a report and emailed it to supply chain person. And then two weeks after that, when they're yelling at you might yield rates are low, and it's all your fault. And you're trying to figure out what the heck you've done. But to be able to start connecting those pieces in real time. I think it'll be amazing opportunity.
And macro fab already does some of that, right?
Yeah, we we've we've I don't know how much we would say we've currently exposed to the customers. But we've been building the data and the interconnectivity and the exposing is coming soon.
Right, right. I mean, you were doing that back when I was there. At least beginning
right. Yeah, we've got a we've learned a lot of lessons along the way. Since there
MacroFab's Misha Govshteyn and Chris Church check in with Parker and Stephen to give his take on supply chains, nearshoring and reshoring.
Chris Church returns to the podcast to discuss the recent outbreak of COVID-19 or Coronavirus in China and how it is impacting Electronics MFGing.
Design for Testing means enabling your product to be tested easier or quicker. But what about the documentation and implementation of the testing?