The Construction Data Integration Playbook: From Siloed Software to One Source of Truth
Most contractors stall on construction data integration because their tech stack grew one purchase at a time: Procore for projects, an accounting system for the books, a separate payroll platform, and a purchasing tool that none of them were ever built to share data with. In this episode of Construction Hot Takes, Adam Cooper and Jeff Robertson break down the three real ways to connect that stack: off-the-shelf API connectors, custom middleware, and a data lake…plus where AI is already starting to replace all three.
The conversation opens with the “300-job treasure hunt” problem: if you have to dig through every active job to find the six or seven with trouble, your systems aren’t giving you visibility, they’re giving you homework. Adam and Jeff walk through why the ERP has to stay the single source of truth for financial data, why Procore and a payroll platform were designed for the department using them rather than the executive suite, and the real distinction between a prebuilt connector that just moves data and custom middleware that can apply business logic, like holding a change order for approval or looking up a tax rate, before it moves anything.
They close on where this is heading: Ascent is already building live dashboards that pull data from Google Ads, GA4, their CRM, and financial software in real time using AI tools like Claude: with no data repository sitting in between at all. It’s an early look at AI stepping into the middleware role itself, and a preview of what construction data integration looks like over the next 12 to 24 months.
Watch the Episode
In This Episode
Why Procore, your ERP, and your payroll system were never built to talk to each other
The real difference between an off-the-shelf API connector and custom middleware
What a data lake actually is — and how it’s different from a data warehouse
How Ascent is already using AI to build live dashboards with no data repository at all
The one exercise to run this week to find exactly where your own systems break
19:33 — How contractors end up with a messy tech stack
Notable Quotes
“If I have to dig through all 300 jobs to find the 6 or 7 that have problems, that’s not helping. That’s a treasure hunt.”
— Adam Cooper, 0:15
“It’s the work, the way it’s designed to work. And you’re not using it the way it was designed. That’s not an architecture problem.”
— Jeff Robertson, 10:25
“They bring all the data in from the different systems to what they call the post office — it figures out where each piece gets routed.”
— Adam Cooper, 14:47
Frequently Asked Questions
What is construction data integration?
Construction data integration is the process of connecting your Procore, ERP, payroll, and purchasing systems so job data lives in one place instead of five. Most contractors add software one purchase at a time, which leaves projects, accounting, and service data siloed — construction data integration ties those systems together so leadership sees one accurate picture.
What’s the difference between an API connector and middleware?
An off-the-shelf API connector moves data between two systems on preset, often one-directional rules. Custom middleware also moves data, but it can apply business logic first — holding a change order for approval, or looking up a tax rate — before deciding where the data goes.
What is a data lake, and how is it different from a data warehouse?
A data lake is a single container holding all the raw, unorganized data pulled from your different systems — Procore, your ERP, payroll — in one place. A data warehouse structures that same data into organized tables, so you know exactly where to look for a specific number.
Why doesn’t Procore talk to my ERP automatically?
Procore, your ERP, and your payroll system are built for the department using them, not the executive suite. Each is designed to be its own source of truth at the project or transaction level, so connecting them requires an API connector, custom middleware, or a data lake layered on top.
Can AI replace a data lake for construction reporting?
Increasingly, yes. Ascent is already building live dashboards that query Google Ads, CRM, and financial data in real time using AI tools like Claude — no data repository required. It’s an early version of AI acting as the middleware layer itself, pulling current data on demand instead of storing it.
What’s the first step to fixing a siloed construction tech stack?
Start by mapping where your data actually breaks — try building one company-level view of your active jobs and note every place the numbers don’t match. That gap is exactly where an API connector, custom middleware, or a data lake needs to sit.
About the Hosts
Adam Cooper: President & CEO of Ascent Consulting. Adam is the primary host of Construction Hot Takes and works directly with construction company owners on operations, growth, and leadership systems. Jeff Robertson: Vice President at Ascent Consulting. Jeff focuses on AI and technology adoption, ERP execution, and the operating detail behind fractional COO engagements with construction companies.
Not Sure Where Your Own Systems Break?
Most contractors don’t find out their systems are disconnected until a report is wrong or a job goes sideways. With a free 30-minute consultation from Ascent Consulting, we’ll help you map exactly where your data breaks and what it’ll take to connect it. Book a Free Consultation
Join our mailing list & gain more construction business insights from our experts.
Episode Transcript
[0:05] Adam: Hi, thanks for tuning in. The episode today is to talk about in my mind.
[0:15] Adam: The way this came about is I was talking to a client and he said, look, we’ve got like 300 jobs going in our company, and if I have to dig through all 300 jobs to find the 6 or 7 that have problems, that’s not helping. That’s a treasure hunt. Yeah. And I said, you know, it’s a great point.
[0:35] Adam: And we started talking about what are the systems you have, what are the dashboards you need, what are the KPIs you’re looking for? What do you want to see kind of lend to a couple of recent projects we’ve done. It’s work. It’s part of a couple of projects I’m currently working on. And and so it turned into a discussion about siloed systems, off the shelf integrations, custom middleware, building dashboards, reporting layers of enterprise data, data lakes, SQL, SQL tables, all this different stuff.
[1:06] Adam: And so I thought it might be fun to have a conversation where we can kind of break this down for the listeners and the viewers, people who are maybe having similar struggles, or they’re looking for answers for how this stuff all works, or how do you make it all work.
[1:14] Jeff: Right? I’ve heard of a data lake. How is that the same or different than a data warehouse?
[1:23] Adam: Yes. Right. So so I don’t know exactly know how to start, but we’ll kind of start, you know, with, with maybe the question that we get the most or that we’ve, we’ve talked about the most that we hear, which is look, I’ve got say I’ve got Pro Core and I’ve got sage intact and I’ve got miner from my payroll, and I’ve got Kojo for purchasing, and I’ve got buildups for the server side of my business.
[1:48] Adam: But these things don’t all talk like I need
[1:53] Jeff: Some do some don’t.
[1:58] Adam: I need I need one source of truth, you know, I and and and what I usually say is, look, the softwares are built for the people who are using them at the department level.
[2:02] Jeff: Right
[2:07] Adam: They’re not made for the enterprise level, the executive suite, they, they shouldn’t, but they, they want having to go into three 4 or 5 six systems sometimes to get the data.
[2:12] Adam: And now they’re pulling it into spreadsheets because they don’t have a way to look at all of the information in one place.
[2:20] Jeff: You make a really good point about the project level that I think people do miss. That is that they are for the most part, there are exceptions and they’re getting I think software developers have figured this out, and they’re starting to think about it more in the enterprise level.
[2:29] Jeff: But you’re right. Most of those are project level tools.
[2:36] Adam: Yeah. Pro course for the project managers, the for the accounting people. The payroll system is for those people. Build ops for the service people.
[2:42] Jeff: Well, even in some cases there’s software now that that that think more enterprise level. I can think of two off the top of my head.
[2:49] Jeff: One deals in change management and the other one deals in AR billings pay applications. They have dashboards that are, you know, you do. You’re working at the project level, but there is a dashboard that shows you enterprise level, company level, what’s going on, except they may or may not connect to your ERP or your CFO is looking at their ERP going, well, I got to open up a whole other piece of software.
[3:15] Jeff: Yes, it gives me a lot more visibility than I used to have, but I don’t want to go to a second piece of software. Right.
[3:28] Adam: And they’re looking for that enterprise level of reporting. So that’s a newer term I’ve heard used. Well, let’s kind of maybe break down. I’ll break down quickly how these systems work and interconnect. So you have your project management system like a Pro Core.
[3:41] Adam: You have an ERP which is really your accounting backbone. And then you have other ancillary systems. You might have a payroll system that’s not part of the ERP, but talks to it like a miner or an ATP. You might have a service platform like build Ops or a service Titan that’s also feeding the ERP i
[3:47] Jeff: Inventory, maybe.
[3:54] Adam: Yeah, inventory management.
[4:01] Adam: You might have Cojo for purchasing something like that or but but ultimately you want the ERP. The accounting system is the is the the single source of truth for the financial data.
[4:08] Jeff: Yes.
[4:16] Adam: Right. We want all the financial data and the reporting to come out of the IRB because that’s what we’re that’s what we’re using to base all of our that’s where the PNL lives.
[4:23] Adam: That’s where the balance sheet lives. That’s where the taxes are calculated or calculated off of that data. So the other systems are feeding that data, feeding that system. And then you’re doing things like making payments and receiving money. And then that information flows back out to the systems to update them.
[4:32] Jeff: In most cases. Yeah.
[4:41] Adam: So like, you know, you create a purchase order in or you push it into the accounting system.
[4:50] Adam: And when an invoice comes in they match it in the counting system. Then they push the cost has been paid and recognized and is simple.
[4:57] Jeff: And they all most work exactly like that. There’s some little differences. But…
[5:05] Adam: Yeah, but in broad strokes that’s how these things are supposed to work. Now, the way you connect these different software systems is there’s there’s two ways.
[5:12] Adam: There’s basically an off the shelf automation or connection, an ERP connector, an API connector. And the way I’ve described that to people is the piece of software has a wall socket that has a special prong configuration, and the API is the plug that they configure that plugs into it so we can read it. I always think of R2d2 in Star Wars, but he has a thing that comes out and he plugs into it and it spins around and then he can talk to it.
[5:42] Adam: That’s the API connector. Yes, that’s how I visualize it in my head. And so software developers create the plug that fits into the socket of the API of the software, and that’s the API connector. And that’s what allows them to read and write to the data tables.
[5:57] Jeff: Do you think that do you think that the vast majority of people understand data tables and like what’s really behind the software that they’re they’re big databases there? There’s a whole bunch.
[6:09] Adam: Of it’s a collection of spreadsheets, a whole bunch.
[6:09] Jeff: There you go. It’s a collection of spreadsheets.
[6:11] Adam: So a data table, like a SQL database, is basically a system that stores all of these different tabs of the spreadsheet or different spreadsheets. So Pro Core has a set of spreadsheets inside of it. It’s data table. It’s all these different grids of data. Each one’s got a field and an address. And then the data base is a.
[6:34] Jeff: Hundreds of thousands of cells in that.
[6:36] Adam: Sure And then and you know, there’s different structures for them. But let’s just use SQL in this example. So SQL is a system that stores all these different Excel sheets. That’s the data base. And each of these softwares has its own database. Now what a data lake is, is a way to pull all the raw data into a common set of database tables.
[7:02] Adam: So you pull all the Pro Core data into one set. You pull your ERP data in, you pull this other one in, and you put them all in a huge container that holds all of the raw data. That’s in essence a data lake. Yep.
[7:16] Jeff: Unorganized.
[7:17] Adam: Correct. It’s just the raw data.
[7:19] Jeff: That’s the important piece. And it’s not organized.
[7:21] Adam: And that might be some people call the enterprise level of data. It’s all the raw source data. Now you can put something like a power BI on top of it that can read all the different data, and then you’re doing the queries and you’re writing and customizing the reporting you want out of all the raw data out of the whole system, which is a collection of data out of all these disparate systems.
[7:43] Jeff: Right? Yes.
[7:44] Adam: So that’s what, in essence, what a data lake is. I hope I didn’t make any IT professionals cringe with that explanation. But for for the common man like you and me, that that should be enough so you can visualize this. But if you don’t have a data lake, you’re not pulling all this into one big, huge collection. You’re just connecting these different systems.
[8:06] Adam: You’re connecting Pro Core to your ERP, this thing, to that thing. And those can be connected two ways. So there’s the off the shelf pre-built connectors that these software companies like H.H. two and Agave and Pro Core and all these other companies make to connect their piece of software to some other piece of software. They’re pre-configured, they have preset rules for which way data flows.
[8:31] Jeff: Sometimes you can toggle. Yeah.
[8:33] Adam: Some you can toggle left or, you know, in or out and some are unit directional. They only go one direction. It only works one way. That’s how they’ve configured it. Yes. So that’s a that’s a prebuilt off the shelf connector. And they have limitations. And they they sometimes cause a lot of the problems that we solve. These are what I’m going to call system architecture problems.
[8:53] Adam: The way this system was built and architected, how they connected these different things, in which way they set these things up to talk, is an architecture problem.
[9:03] Jeff: So I would add to that.
[9:07] Adam: Okay.
[9:10] Jeff: Sometimes, sometimes I think it’s a there’s a process problem associated with that.
[9:14] Adam: Like how people actually do the work.
[9:16] Jeff: Yes. And it’s not it’s not aligned with the architecture. And the other would be they’re trying to use the system counter, I guess, counter to the way it was initially imagined. So therefore the architecture doesn’t work.
[9:38] Adam: I would. I Would, I would suggest that those are all still architecture problems, that when you’re architecting the system, it’s not just the software architecture, it’s the process or architecture, it’s the data flow or the the way you move through the software.
[9:55] Jeff: Here’s why I here’s why I draw a distinction, okay? Because I think by calling it an architecture problem, only in those scenarios sort of gives people who can’t get their head around the fact that they’re doing it wrong. It gives them a pass. It makes them say, we hear this all the time. It’s it’s doesn’t work right. Pro core is broken.
[10:19] Jeff: It’s not working right. I’m quite sure it works just fine. You’re you’re doing it wrong.
[10:24] Adam: It works the way it’s designed.
[10:25] Jeff: It’s the work, the way it’s designed work. And you’re not using it the way it was designed. That’s not an architecture problem. The architecture works fine.
[10:31] Adam: That’s a workflow or a process problem. This is my point. Operational issue.
[10:35] Jeff: That’s my point. That’s not an architecture thing.
[10:37] Adam: Right? So I think that when you’re really architecting the system, you have to think about more than just the software. You have to think about. It’s we would call it operational design, but it’s operational design with a technology component. Like we don’t think about just how the people work. We think about how the software works, too, and then aligning the people and the processes with how the software is meant.
[10:58] Jeff: Well, we’ve said that. We’ve said that over and over again. When you get a new ERP, for example, which is common, the machine, how it’s designed, the architecture, it gets a vote now.
[11:08] Adam: Yes.
[11:08] Jeff: How how you enter the data, at what point in the process matters? It absolutely matters. Because if you a simple example would be there’s a cell.
[11:21] Jeff: You know, a place to enter data in, in whatever your accounting software. And let’s say it’s let’s say it’s like region. It’s pre pre-designed. It thinks that when you’re entering a contract or a new contract you want like name, address, phone number, like a region of the country they’re in. But you don’t have that region is not a thing for you.
[11:46] Jeff: So you use the region cell to track something else you want to track, like the wife’s name of the guy you talk to, and you don’t have any other place to put that, so you just put it in region. I don’t track regions. Mary. Putting that right there. Well, later on when you try to connect that to another piece of software, it’s going to go look at that region cell and try to pull data from it.
[12:08] Jeff: And you’re going to get Mary’s name out of it. And it’s not going to make any damn sense. That’s what I mean.
[12:12] Adam: Gotcha. It’s a little bit of an extreme example, but.
[12:14] Jeff: I’ve seen that example. It’s not extreme okay. Got it.
[12:18] Jeff: Client did that recently.
[12:20] Adam: Really.
[12:20] Jeff: Yes.
[12:32] Adam: Interesting. So that is a great lead in to me talking about middleware. So middleware instead of using an off the shelf connector you can build custom middleware. We’re doing this with a client right now. The difference between the off the shelf connector and middleware is that middleware not only moves the data, but it can make decisions for you.
[12:45] Adam: You can preprogrammed it with business process decisions. Hey, I only want to move change order dollars over to this system once it’s moved to an approved state. Yes, if it’s over a certain dollar threshold, I want it to go to a staging area where somebody else has to approve it besides the project manager. So it’s like got business logic built into it, so you can build that into custom middleware, whereas that logic is oftentimes not available or predetermined on an off the shelf connector.
[13:24] Jeff: I’d also add that we’ve had we’ve had Greg and I did a podcast episode about automation versus AI. Yes, that would be a definition. That would be the automation side of things.
[13:33] Adam: Correct more like a custom middleware. Like we’re working with Morpheus deterministic. It’s deterministic, it’s predefined rules, and it’s more of an automation layer. But it can do it can manipulate data. It can also do math on data before it moves it. We have one case where it’s taking raw cost. It’s looking up sales tax amounts based on business process rules.
[13:57] Adam: Hey go look up the address, find the applicable tax rate, apply it and then move fully and add the tax line when you move the data into the.
[14:06] Jeff: Rest to simplify it. It’s old fashioned. If then logic.
[14:10] Adam: Yeah. Conditional logic. Yeah for sure. It’s also threshold based logic which I guess is kind of the same thing. Don’t do this until this is done right. Like don’t move the data until this switch.
[14:22] Jeff: If it’s if then if then if then.
[14:23] Adam: Yeah. So that’s middleware. Middleware is is configurable with business process API connectors. And it can feed a data lake. But it doesn’t necessarily have to build a data lake. We have a we have one right now. And they they they call they bring all the data in from the different systems. They bring it to like what they call the post office.
[14:47] Adam: They figure out where it gets routed. That’s based on the rules in the post office. You pull the data in, it’s got an address for where you want it to go, and then it moves it where it wants to go, assuming it satisfied the business logic that you’ve pre-programmed it with. So that’s middleware.
[15:01] Jeff: I like that term. That’s good.
[15:02] Adam: Yeah I thought it was really clever. So they used that. So again middleware doesn’t necessarily have to have a data lake. But there’s an opportunity as it’s pulling in all this data to put it into the data lake. It could be feeding the data lake. But again middleware is only going to get data that you ask it to go get.
[15:23] Adam: Whereas a an API connector with an open API and a data lake that’s doing a basically a sweep, you could have it grab all the data, not just the things that.
[15:32] Jeff: You see a gigantic vacuum.
[15:33] Adam: Yeah, that’s that’s kind of the difference. Right. So but once you have it, once you have the data moving where you want it to, now you can start figuring out how to get those company wide reports that have data from different systems. You can either pull it into the like, say, the ERP, if it’s got places to store all of that, or you have to pull in some type of like a SQL database where you can access it.
[16:00] Adam: Like if you want to see reports on RFI status out of Pro Core and profitability out of the ERP and payroll data, you might need to have some type of a place to store all of that that the power BI or the visualization software can access.
[16:19] Adam: And I think where we’re going now, what I’ve seen recently and this is mid 2026, is that like with Anthropic and Claude, you can get plugins to these different softwares and then Claude can do the data, can collect the data from different systems and then create the visuals in real time.
[16:36] Jeff: Yeah. So it’s yeah, it’s coming to a point where it can be the middleware.
[16:40] Adam: Yes. And it doesn’t need a data lake to produce the enterprise level visual data and reporting that you need. It’s basically building its little enterprise layer of data collection and then producing visuals.
[16:58] Adam: So that’s where we’re at today.
[16:59] Jeff: I would still think that you would need would you still need I’m going to use the word repository wooden Claude or coworker or whatever. Wouldn’t it need the the repository of all that or is it’s pulling it in real time.
[17:18] Adam: Pulling it in real time. We’ve built these already where we are pulling in data out of, like our Google Ads account, Ga4 Google Analytics, out of our CRM and out of our our.
[17:32] Adam: Financial software. And we’re creating real time dashboards with live data that are updating every five minutes now. And there’s no repository. It’s just it’s.
[17:47] Jeff: The data lives where it lives.
[17:47] Adam: And basically Claude’s doing a query API query and saying, hey, what’s the current data set? And it’s pulling in the current data for the whatever the parameters are that we said, hey, we want you to pull in the last 24 hours. So every hour that data shifts by one hour, right. So that is so it’s starting to do it without.
[18:09] Adam: And this is, you know, the beginnings of this what we’re doing it without a data repository. That’s a great way of thinking about a data lake as a data repository. Again, it lake or a data warehouse or something is really the raw data. It’s not. And it’s all of it. Typically it’s not selective.
[18:25] Jeff: As I understand the difference between the lake and the warehouse is that the lake is literally it’s it’s it’s disorganized. It’s I don’t know if chaotic is the right word, but it’s it’s just a big mix of everything. Whereas if it’s in a warehouse. There are rows structured. So it’s more structured. So you know, you know where to go.
[18:46] Jeff: Look for your core data. You know where to go to look for your spectrum data. You know where to go. Look for your clear story data as opposed to.
[18:55] Adam: We might need to get one by my data experts in to maybe go do a deeper dive on this, okay? Because we’re kind of at the limits of what I’m comfortable saying out loud, right? Okay. I’m I’m at the edge of my I know what I know and I’m venturing into I know that I don’t quite know that territory.
[19:16] Adam: I’m in the the threshold of knowledge.
[19:19] Jeff: Well, what I just said was the extent of mine. So we’re even good.
[19:22] Adam: We’re at the same level.
[19:23] Jeff: Yeah.
[19:24] Adam: So I hope that was informative. I don’t know if there’s more to add to that, but I thought that it would be really good to kind of set the stage. There’s a lot to talk about, about what you can do with that data, but letting people understand how these systems connect, how how these systems work. You know, the difference between some of these terminologies?
[19:41] Adam: I think that could be really helpful for folks.
[19:44] Jeff: Well, I think it’s a really good point because we we are increasingly I feel like in any way maybe I’m but we’re increasingly getting calls from clients who have this data or this tech stack rather, that’s very siloed. And they.
[20:02] Adam: They say, well, the data is all there, but I can’t see it all in one.
[20:05] Jeff: Because because they’ve been adding these things like, you know, it’s just like sediment. It’s just kind of they keep adding it as they go. They started with an ERP. Maybe it was QuickBooks, maybe it was something else. And they probably we hear this a lot like, well, I got this and it was supposed to solve all my problems.
[20:19] Jeff: That’s what’s called an ERP. But then I realized project management sucks. So I had to go get a project management piece. And then I realized, oh, we actually well, we didn’t do inventory. We didn’t have any inventory. But when we added it, we had to get a whole other thing. So they just kind of added over time. It’s somewhat organic.
[20:36] Adam: Maybe they’re going with best in breed is when I hear a lot. Yes. We went and got the best software for project management, the best, the best service software, the best, that’s the best. That. And then they wind up with siloed data.
[20:46] Jeff: Well, a lot of these, you know, contractors as a rule is my rule. I don’t know if it’s everybody else’s rule okay. We’re pretty contractors are pretty like do it yourself kind of people like like.
[21:00] Adam: Yeah, we build shit.
[21:01] Jeff: Yeah. So it’s like we can figure this out and they end up with a tech stack. That’s probably all really good stuff. But you eventually kind of go, I’m so tired of going to 14 different things to find stuff.
[21:15] Adam: I’m talking to a company right now. They’re they’re upwards, you know, several hundred million dollars. And they’ve done that over the last decade. They have they have like a very powerful ERP accounting platform. They’ve got some best in class, best in breed softwares, all the data sitting in different systems. And they showed me what they what they built their proprietary software. And it’s pulling the data from the different systems and updates overnight. So it’s updating some type of a SQL database overnight. And it gives them everything they need about the company and the projects in one platform. And it looks like a huge Excel sheet that updates. And they’ve been using it for years. And they know how it all works, but they’re tired of it and tired of maintaining it.
[21:58] Adam: And they want something more state of the art. And now they’re looking at how do we get a new platform that replaces this. And so we’re talking about how we can help them not only figure out what that new platform is, but how do we get it working, how do we find the right partner to work with, and how do we ensure that it gets done in a timely fashion?
[22:16] Adam: So it’s the way the world, you know, and you said, you know, contractors are pretty do it yourself. We can figure this out. But this is stretching the boundaries of what I would expect a construction company to really be focused on. This isn’t your core business.
[22:31] Jeff: No. Well, that’s a that’s a really good point. I mean, even when we were young project managers, we had IT departments. And the IT guy came with a disk every maybe 6 or 8 weeks and said, I need you to go get a cup of coffee. And when you come back, you’re just gonna have to relaunch in. Everything will be fine.
[22:52] Jeff: And he was updating our software, like on our machine desk to desk to desk to desk.
[22:57] Adam: I do remember those days. And that was the 90s, for those of you listening at home.
[23:04] Jeff: But I guess my point is, is even then it was this software. We shouldn’t think about things the same way we did. It was expected. Nobody expected anything to be able to talk to each other. Nobody expected the system to be able to do the analysis we expect.
[23:22] Adam: I got an email at work until 1997.
[23:24] Jeff: I had it in 90 c, I came out of school in 94 and I had email in 95.
[23:27] Adam: At work?
[23:29] Jeff: Yeah.
[23:32] Adam: I had a personal email in ’96.
[23:34] Jeff: I didn’t get a lot of email, by the way, at that time, but I.
[23:37] Adam: Nobody else had
[23:38] Jeff: Cause no one else had it right.
[23:40] Adam: It’s like being the only guy with a with a roll of stamps, I can send him out. Nobody knows how to mail anything back to me.
[23:45] Jeff: That’s how it became such a scheduling nerd. Nerd is. Because I had I, I said something to someone. I said that I had learned how to use P6 in school, and that was in DOS.
[24:02] Adam: And then you were the scheduling guy.
[24:04] Jeff: I was at beers at the time, and they had just P6 had just come out with the windows. I’m like, hell yeah, I’d love to work in that thing. And I became the scheduling guy.
[24:14] Adam: There you go.
[24:15] Jeff: Because they were like, we don’t know how to use this. Load this on your machine and figure it out. I’m like, okay.
[24:19] Adam: Well, I hope this episode was informative. Again, if you’d love to talk about this more in depth, you can write to Jeff or I directly. Our emails are in the show notes and we’ll see you on the next episode. Thanks for watching.
[24:32] Producer Josh: Hey, Producer Josh here with The Change Order: build a better business one takeaway at a time. And if finding your struggling jobs feels like a treasure hunt across hundreds of projects, here’s the key idea: tools like Procore are built for running projects, not running the company. So a company-level view means pulling data together from a bunch of different systems. You basically have three options: off-the-shelf connectors that snap two systems together, custom middleware that routes your data by your own rules, and a data lake that pulls everything into one place so you can consistently query it. Looking ahead, AI may start building a lot of that middleware itself. Until then, remember: one source of truth beats a treasure hunt every time. Go ahead and share this with whoever needs it. Like, subscribe, and go out there and build better.
