More Than Saving Engineers' Keystrokes — John Thomas & Scott Brickler (Episode 1)
The Integrate Intelligently Podcast — with John Thomas and Scott Brickler (CADTALK)
John Thomas, Marketing Manager at CADTALK, sits down with CEO Scott Brickler for a conversation that goes beyond the usual pitch — why the real value of CADTALK isn't just saving engineers keystrokes, what disconnected engineering data actually costs a manufacturer, and why "consistently wrong" beats "sporadically right."
Speaker note: same setup as the other two-person episodes — lines attributed directly to John and Scott.
Introduction: Why This Conversation Is Different From "Saving Keystrokes"
John: Welcome back to the Integrate Intelligently podcast. I am not Jeff Brickler — I'm John Thomas from CADTALK, our marketing manager. Today I've got our CEO, Scott Brickler, with me for a conversation that's been a long time coming. Scott, I know you're on all these podcasts, but today we're going to hone in on some things about CADTALK the product, and go a bit bigger too. A lot of times when we talk about CADTALK, it's framed around saving engineers keystrokes — but we want to talk about what that actually means. So let's open with that: what does it mean to you that CADTALK does more than just save engineers some keystrokes — important as that is?
Scott's Origin Story: From Engineer Scratching an Itch to Seeing the Bigger Picture
Scott: I go back to the original idea — being the founder, this problem was scratching an itch I had. We've told this story on the podcast before, but it was very much the same mindset we talk about with engineers: I had to do this job, it wasn't fun, and I wanted to find a way to save time on it. Very much a "what's in it for me" situation as the engineer — saving engineer keystrokes, which makes a lot of sense.
But as I did consulting and ERP implementations and worked with customers, I saw how these systems actually work, and if you zoom out, you realize there's a purpose behind why this work happens in the ERP based on the engineering design — and then you ask, why do we need to do it at all, how do these systems actually work? That's what made me understand the problem we're solving is so much bigger than the easy-to-see ROI — the "this person isn't doing this task anymore, there's an opportunity cost to their time" math. That makes sense, but it's not the whole story.
Why Everything in Manufacturing ERP Runs From the Bill of Material
Scott: Think about how ERPs work, especially for manufacturing — everything is driven from the core bill of materials in the ERP: the items, the BOM, the routings. When ERP gets sold to manufacturers, sometimes they're fixing a data issue around accounting, but a lot of the time they're fixing scheduling problems — they can't deliver on time, things cost way more than expected, they don't know what things actually cost, they're not buying the right things at the right time, lead times are ballooning. That's the whole premise behind buying the ERP — the promise that it'll solve all of that.
The Demo Problem: ERPs Always Work With Perfect Data in Demos
Scott: And of course, when they demo the ERP, all of that gets solved — because the demo runs on perfect data. Everything meaningful in an ERP — MRP, scheduling, planning, quality — depends on that bill of materials being correct and accurate. That's the unsexy part of the whole thing. If that core data is right, the ERP works like magic — that's why people pay six or seven figures for these solutions. That's the promise. But then at the end of the day, actually getting that data right is hard, and it's not fun. That's exactly the work I didn't like doing — which is why I wanted to save myself the keystrokes in the first place.
"The ERP Isn't Broken — the Data Feeding It Is"
Scott: Somebody has to know how you're going to build something — which machines it goes through, how you're going to buy the materials — all of that has to be figured out for the ERP engine to actually run. The problem CADTALK was really solving was: how do I get that unsexy data into the system so the ERP can actually do its job and the company can realize the investment they made in this very large purchase? Framed that way, CADTALK looks like very cheap, very low-cost insurance to make sure that happens — and it does it fast.
I come from a partial engineer-to-order background, and one of the biggest differentiators in that market is speed — lead time, how fast you can move information through a process to get a result. Every point where something sits, or a decision has to get made, adds to that lead time. To the customer, that shows up as "I ordered it today, I get it in 200 days" versus 100 or 90 — and whoever delivers earliest, lowering the customer's risk, wins. That's a real differentiator for a manufacturer. If I can take the time between an engineer's brain and the finished design down to almost zero, how much of that lead time have I cut, and how much competitive advantage has that manufacturer gained?
John: I have to say — I love when I can ask a guest one question and get ten minutes back. Makes my job as an interviewer very easy. Appreciate that.
Scott: No apologies needed at all.
John: But here's the idea I keep coming back to — there's a lot of, rightfully so, resource and time spent on "which ERP should we select?" And that's valid. But almost what I'm hearing you say is that, to some extent, it barely matters — because if your data isn't doing anything for you, you've just got a piece of software. Your ERP isn't really working for you, no matter which solution it is.
Why "Consistently Wrong" Beats "Sporadically Right"
Scott: That's exactly right. It's the same as a diet — most diets work, the question is which one you'll actually stick to. The diet itself is the unsexy part: eat less, move more. Same thing with ERP — the unsexy part is getting the data right so the system actually has something to work with, and that's the part most people don't want to do.
John: Right — and it's not what sells the ERP either. You're going to hear a lot more about AI, or about scheduling features, when you're evaluating an ERP investment. So the ERP itself isn't broken — it's the data feeding it that's broken, or at least incomplete. We talk to a lot of manufacturers who know that gap exists. But what does the actual cost of that gap look like, beyond just the keystrokes?
What Disconnected Engineering Data Actually Costs (Beyond the Obvious)
Scott: It's a softer cost, like any opportunity cost — harder to quantify, but that doesn't mean it doesn't exist. People like sure bets: "if I'm paying an engineer this much and save half his time, I save half that money." Except you don't — you're still paying him regardless. It's still a soft cost, just measured differently.
What's the opportunity cost of delivering 20 days late? That's hard to measure. Ordering the wrong part is much easier to measure — tell the ERP the wrong thing and it will act on it very quickly, very expensively. That's an easy one to point to. But there's a broader idea: you invest money to make an improvement, and everything comes with a cost — not just the software cost, but implementation, disruption, and process change, without always getting the benefit.
I've said this before: any change you decide to make in a process comes with a guaranteed 20% reduction in productivity during the transition, but not every change comes with a guaranteed upside. So if you're going to make a change, you'd better be confident it's at least a 20% improvement. I've seen ERP implementations end up 40% worse than where they started, because it got too hard and they compromised away all the benefits they hoped for — just to get back to something at least 20% worse than their starting point. A lot of that stems from these hard, unsexy pieces being genuinely hard to execute.
On cost specifically: ERP itself often runs six to seven figures. CADTALK, by comparison, typically comes in somewhere between $15,000 and $50,000 in licensing — a fraction of the ERP cost, for a piece that's this critical to actually getting the data in.
John: If that's such an important piece — getting that data in, and CADTALK does it well — what do you hear, or what do you picture, as the actual blockers keeping someone from making that investment?
Scott: I think it's that people picture it as a light switch instead of a dimmer — a binary. Could you get bill-of-material accuracy without a tool like this? Sure, but it requires a lot of discipline. It comes down to whether a tool increases, decreases, or is neutral to the likelihood of that outcome happening. Depending on people to be consistent day in and day out is genuinely difficult — people are creative, but they're not naturally consistent, and processes are hard to maintain. You need SOPs, managers, oversight — a lot of overhead just to keep people doing the same thing reliably.
So yes, you could do it without a tool — but that doesn't guarantee the outcome, and implementing a tool badly doesn't guarantee it either. The difference is that once it's set up correctly, software is consistent — it does the same thing every single time, day or night, it doesn't sleep, doesn't care, just keeps going. If you could buy an insurance policy guaranteeing consistency on your core data, why wouldn't you? People sometimes say, "well, CADTALK could be wrong too" — sure, but it's consistently wrong, which is so much better than being sporadically right. You can fix consistently wrong. You can't fix sporadically right.
The Sports Analogy: Why Consistency Is What We Actually Marvel At
John: Having a background in sports and practice, my mind goes straight to repetition — fielding ground balls, shooting free throws. Watching film, making the same motion over and over, letting a coach adjust your elbow or your glove angle — that's how improvement shows up. But it's hard to admit something is consistently wrong, because we want it to be perfect. Especially in engineering — you want it to be perfect, don't you?
Scott: Yeah, I do. And to build on your sports analogy — think about what we actually marvel at in sports: bowling, golf, archery, all these things built entirely on a human's ability to perform a consistent behavior over and over. We marvel at consistency itself. Only the best of the best in the world are the most consistent.
Think about what it takes to get there: repetition. If you're a basketball fan, Steph Curry is an incredibly gifted shooter, but he's also put up an enormous number of practice shots to become the best shooter to ever play. Only the very best who put in that much work can be considered consistent — and software does that by default.
The Machine vs. the Human: What Software Does by Default
John: Exactly — that reminds me of a great example. If you're familiar with Mark Rober, the former NASA engineer with the huge YouTube following — he put out a video where he built a robot goalkeeper that could stop any shot, and put Cristiano Ronaldo up against it in a penalty shootout. Ronaldo couldn't beat it, even though he's one of the five best soccer players to ever play the game.
Scott: Oh yeah — exactly. It's just really hard to beat a machine at consistency.
