In this episode of the Pipeliners Podcast, host Russell Treat joins Mike Radich, Senior Account Executive at LiveEO, for a live webinar conversation on what happens after a right-of-way issue is identified — how it moves through the organization, how it gets prioritized, and how it ultimately reaches the field for resolution.

Drawing on more than thirty years of pipeline operations experience, Russell applies principles from control room management, alarm management, and human factor science to the emerging challenge of real-time satellite-based right-of-way monitoring.

Right-of-Way Monitoring Show Notes, Links, and Insider Terms

• Right-of-Way (ROW) Monitoring — the ongoing process of surveilling and inspecting the land corridor along a pipeline for encroachments, excavation activity, vegetation, and other physical changes that could affect integrity or safety
• Situational Awareness — a control room operations concept referring to an operator’s real-time understanding of the state of a system: whether conditions are normal, abnormal, or emergency; applied here to right-of-way oversight
• Alarm Management — a formal discipline, governed in the pipeline industry by PHMSA’s Control Room Management rule, focused on ensuring that every alarm is meaningful, requires operator action, and is documented with a clear response; designed to prevent alarm floods
• Control Room Management Rule (49 CFR Part 192/195) — the PHMSA regulation published in 2010 requiring pipeline operators to establish and maintain written control room management procedures, including alarm management, fatigue mitigation, and training programs
• Alarm Flood — a condition in which the volume of alarms arriving at a controller’s console exceeds the operator’s capacity to effectively respond; research cited in the episode suggests operators can handle approximately six alarms per hour effectively
• SCADA (Supervisory Control and Data Acquisition) — the system used to remotely monitor and control pipeline operations, including pressure, flow rates, valve positions, and leak detection data
• High Performance HMI (Human-Machine Interface) — a design philosophy for control room displays that prioritizes the rapid detection of abnormal conditions through contrast, layout, and information hierarchy; associated with practitioner Ian Nimmo, mentioned in the episode
• Human Factor Science — the study of how human cognitive and physical capabilities interact with systems and environments; applied in pipeline operations to design workflows, interfaces, and procedures that optimize operator performance and reduce error
• Pipeline Safety Management Systems (PSMS) — a framework promoted by API (RP 1173) for integrating safety into all aspects of pipeline operations, including continuous performance improvement, root cause analysis, and documented processes
• API RP 1173 — American Petroleum Institute Recommended Practice for Pipeline Safety Management Systems; provides operators a structured approach to managing safety risk across the pipeline lifecycle
• PHMSA (Pipeline and Hazardous Materials Safety Administration) — the U.S. Department of Transportation agency responsible for regulating pipeline safety and hazardous materials transportation
• Verifiable, Traceable, and Complete — the PHMSA documentation standard for pipeline records, requiring that records identify who created and approved them, show the chain of actions taken, and fully capture all required information; central to closed-loop workflow design
• Third-Party Damage Prevention — one of the leading causes of pipeline incidents, involving unauthorized excavation or encroachment on the pipeline right-of-way; real-time ROW monitoring is discussed in the episode as a significant mitigation tool
• 811 / One-Call (Damage Prevention) — the national system in the United States requiring excavators to notify pipeline and utility operators before digging so that underground lines can be marked; referenced in the episode in the context of integrating ROW monitoring with marking workflows
• Satellite Imagery / Near Real-Time ROW Monitoring — the use of satellite-derived visual or analytical data to detect physical changes along a pipeline corridor, enabling faster identification of encroachments, excavation activity, and other threats compared to traditional aerial or ground patrol methods
• Digitalization — the process of converting manual or analog pipeline operations and data collection processes into digital, automated workflows; discussed in the episode as a driver of increased data volume and the corresponding need for prioritization systems
• Closed-Loop Process — a workflow design in which every identified issue is tracked from identification through field action through verification and documentation, enabling performance measurement and continuous improvement
• Escalation Rubric / Priority Triage — a defined framework for classifying identified issues by severity (e.g., critical, high, medium, low) so that field and office resources are directed to the most important items first
• Doug Rothenberg — alarm management subject matter expert referenced by Russell Treat as an influence in his development of alarm management expertise
• Ian Nimmo — high performance HMI subject matter expert referenced by Russell Treat; associated with the discipline of designing control room interfaces to optimize operator situational awareness
• Intersect Corporation — Russell Treat’s company; a pipeline operations technology and consulting firm
• American Petroleum Institute (API) — episode sponsor; the primary standards-setting body for the U.S. oil and natural gas industry, referenced throughout in the context of pipeline safety standards and frameworks

Right-of-Way Monitoring Full Episode Transcript

Speaker (Announcer): Welcome to the Pipeliners Podcast, Episode 444, sponsored by the American Petroleum Institute. Driving safety, environmental protection, and sustainability across the natural gas and oil industry through world-class standards and safety programs. Since its formation as a standard-setting organization in 1919, API has delivered more than 800 standards to enhance industry operations worldwide. Find out more about API at api.org.

The Pipeliners Podcast, where professionals, bubba geeks, and industry insiders share their knowledge and experience about technology, projects, and pipeline operations. And now your host, Russell Treat.

Russell Treat: Thanks for listening to the Pipeliners Podcast. I appreciate you taking the time, and to show the appreciation, we give away a customized Yeti tumbler to one listener every episode. This week our winner is Brian Moorhead with the Canadian Valley Technology Center. Congratulations, Brian. Your Yeti is on its way. To learn how you can win this prize, stick around till the end of the episode.

This week, we’ll be listening to my appearance as a guest on the live LiveEO webinar hosted by Mike Radich, where we talked about closing the gap between field execution and right-of-way monitoring — basically relating real-time satellite imagery and how we should think about that in terms of dealing with response.

Mike Radich: Hello, everybody. Thank you for joining us today. I’m Mike Radich. I’m Senior Account Executive here at LiveEO. And today’s session is focused on closing the gaps between insights and field execution: right-of-way monitoring. We’ll be exploring what happens after an issue is identified, how it moves through the organization, how it is prioritized, and how it ultimately gets resolved in the field, and what lessons from control room operations can strengthen that process.

I’m joined today by Russell Treat, host of the Pipeliners Podcast and CEO of Intersect Corporation. Russell brings more than thirty years of experience in pipeline operations with a background in control room systems, SCADA, leak detection, and operational workflow discipline. Thanks for joining us today, Russell.

Russell Treat: Glad to be here, Mike. I look forward to the conversation.

Mike Radich: Yeah, for sure. So let’s just dive right into this. Pipeline operators today have greater visibility into potential issues along the right of way. The question is what happens once the insight enters the organization. So when a new issue is identified, what should a disciplined workflow look like from that point forward?

Russell Treat: Well, I think that’s a really good question. And I would say that most pipeline operators are beginning to explore this. They’re trying to figure it out. My background is more in the control room operations side of things, where you’re sitting and looking at screens and monitoring pressures and flows and those kinds of things. There are a few key principles around situational awareness and what I would call permission to operate — which is kind of an alarm management discipline — that I think apply to this.

Situational awareness is the idea of: I need to know what the state of my system is. Is it normal or abnormal? And I think one of the things you’re seeing with some of these workflows around capturing data off of satellites and other kinds of imagery and analyzing that data is the idea that my right of way — I should be able to maintain situational awareness about my right of way. And that’s really what we’re trying to get to: get where I need to go without being bothered by the things I don’t need to be bothered by.

Mike Radich: Yeah, that makes sense. Try to get to that place. So with that in mind, where do you often see breakdowns early in that process?

Russell Treat: Well, there are two fundamental breakdowns in any kind of control room operation. One is not giving the controller or the person at the console meaningful, actionable information. And the other is giving that person too much information. The too much information problem is often what you see when new kinds of digitalization processes come in, because the assumption is, “Well, I’ll just give them everything, because if I give them everything, they’ll figure it out.” And that’s actually not the way the human brain works. The human brain is really designed to work on the things that are complex, that the machine can’t address — if that makes sense.

Mike Radich: Yeah, it makes sense. And I think that’s the big thing with today’s society, right? There’s a lot of data coming in, and it’s about how to effectively utilize that data and get to the right place and use it effectively. So it makes sense. So as signals increase, not every issue carries the same urgency. What does effective triage look like in practice?

Russell Treat: In the control room, there’s a whole discipline around this called alarm management. And I’ve got to give a little bit of history to make this make sense. If you go back twenty years in the pipeline world — so we’d be talking about early- to mid-2005 timeframe — computers were becoming prolific throughout control systems. Particularly Windows computers were becoming very cost-effective. But the graphics engines and the ability to display things in a complex way were basically not there yet. So what you tended to see was lists of numbers changing color, and a list of alarms.

And the kind of where we went early in the days of automation was: we put an alarm on everything. And the problem with that is you put people into what’s called an alarm flood. There’s been research done that the typical number of alarms a controller can effectively deal with in an hour is six. And twenty years ago, the average number of alarms coming to a console was probably twenty-five to one hundred an hour. So twenty-five an hour is effectively an alarm every two minutes, and there’s no way I can process all of that.

One of the things that was done in the pipeline world — in 2010 they published a rule called the Control Room Management rule — and one of the requirements there was to do alarm management. The whole idea of alarm management is to make sure that the alarms that come in are meaningful, require action, and are documented in a way that the required action is clear. So I think anytime you start looking at trying to do real-time data processing to improve operations, you’ve got to take a look at: what data am I sending? What’s the maximum quantity a human being can handle? And then how do I get the system to automatically prioritize their work?

Mike Radich: That makes sense. And you definitely have to utilize the resources you have. So how should organizations structure prioritization and escalation so that critical risks don’t get buried?

Russell Treat: It goes right back to what we do in alarm management. The primary thing we’re doing in alarm management is trying to make sure that every alarm is a real alarm. Said another way: there are a lot of things that occur that I might want to search through or know about, but I don’t need to take action on them. For example, if I send a command to close a valve, I probably need to know that the valve closed, but I don’t need to do anything with that. There might be other things occurring — communication volumes or system health indicators — that are useful information but don’t require action.

Versus if I get a leak alarm, that’s critical and I need to work on it right now. I need to put everything else to the side. So when you think about a workflow around real-time data, one key thing is: how do I separate those things that don’t require action but are useful for analysis, from those things that require action? And then within the things that require action, I probably want to establish a rubric to determine what is critical, high, medium, and low severity, so that I end up with a work list with the most important items at the top.

Mike Radich: That makes sense. And I think with today’s world and just how things go, sometimes you get really busy or you just don’t have the resources available. So what could happen if that structure isn’t in place? Obviously if you come in with a plan it’s good, but if it’s not identified, what could happen?

Russell Treat: There are known pipeline incidents where critical notifications got buried in a flood and got missed, and led either to an adverse outcome or led to the magnitude of the adverse outcome being greater. So if you think about, say, sixty alarms an hour — one a minute — and then I have an issue or incident occur and I get a burst of alarms around that incident, and if I enable the ability to just go, “Yeah, I’ll acknowledge all that,” I silence all the noise. When I do that, I run the risk that there’s something critical in there that I missed.

The second thing is: what do people do if they’re buried in information? What does the human mind do when you get saturated with information?

Mike Radich: Kind of goes blank, right? Shuts down a little bit.

Russell Treat: Yeah. You turn it all off. And in fact — this is an analogy — in Vietnam, all of the fighter and bomber aircraft working in that environment had all kinds of radar and missile detection systems. So when Navy fighters would fly feet-wet over the ocean and then go feet-dry over the ground, immediately all of those systems would just light up. What they learned to do very quickly — because all of a sudden they’re looking at all this and paying attention to all the systems — is that if someone fires a missile, they don’t see it tracking to the airplane. So what they learned to do was turn all of that off and look for the missile flash. The analogy is: in any real-time data feed, how do you turn off the noise and find the missile flash?

Mike Radich: That makes perfect sense. So you kind of mentioned it before — you get a lot of insights and data that comes through. And I think we can both agree that without ownership, it doesn’t really translate into anything. The data just sits there and nothing happens with it. So how important is clearly defined responsibility from identification through resolution?

Russell Treat: Critically important. Without it, the data is of no use. That’s kind of the short answer. I’ve done a number of podcasts about this subject related to what’s going on with image processing, because that’s typical of a lot of processes that are beginning to convert from something that used to be highly manual to something that’s highly automated. And we’re not just processing images — we’re doing all kinds of mathematical and statistical analysis. What’s critical in that process is we need to be able to prioritize the output so that it comes out saying: here’s what you need to look at first, second, third. And here is what you’ve got to look at today, this week, or when the workload allows.

Mike Radich: That makes sense. Where do you most commonly see accountability gaps emerge? With all this data and process in place, where do the gaps typically come from?

Russell Treat: It always boils down to communications and roles and responsibilities in the midst of something critical. I’ll use a cockpit analogy. A lot of people are familiar with the incident where Captain Sully landed the aircraft in the Hudson River. If you watch that closely from the viewpoint of what’s going on in the cockpit, there are three critical roles operating through that emergency: the pilot, the co-pilot, and air traffic control. They’re all working the problem, but it’s very clear that Sully is in charge and he’s directing who gets talked to next. If there was any lack of clarity about who owns what role, that airplane would not have landed safely.

There’s an analogy there for any real-time or critical workflow. In the control room, where you get into issues often — particularly in larger control rooms — is in what you’d call team training: the interaction between the controller, the field operations management, the control room operations management, and other parties, making sure they can all communicate effectively, and that everyone understands who is operating in which role.

You’re going to have the same kind of issue even in a daily workflow. If I’m getting updated imagery every day from my pipeline, I need to know: who is responsible for taking action? In what timeframe are they supposed to take that action? And if there are multiple actions, who is in charge and how are each of those actions handled? Or again, it tends not to show up until things get really critical.

Mike Radich: It’s like when you put it in action, right? That’s kind of when you see it show up the most — when something comes out of nowhere and things get really critical.

Russell Treat: Or said another way: it’s when your cognitive capacity gets undermined because of process. What you’re trying to do is build a process that optimizes cognitive capacity for the people doing the work.

Again, using the Sully example — if you watch that movie, it’s very clear Sully is in charge, the co-pilot is running down tasks and trying things, and the traffic controller is looking for alternative landing zones and notifying emergency authorities. Sully is not worried about any of that. He’s just flying the airplane.

It’s different, of course, when you’re talking about capturing imagery and working the right of way. But you know, that process has been: we fly the right of way once a week or once every two weeks, we get this information, somebody goes through it and identifies the things to look at, and then another week or two later we get more information, and then a week after that we take action. Where we’re moving to is monitoring that right of way in real time, because the real risk on the right of way is not the slow encroachment. It’s the guy that drove the backhoe onto the right of way.

Mike Radich: That makes sense. And I think that kind of goes to my next topic. You mentioned having a plan in place, and I think the next part is execution. The transition from analysis to field action is where risk is actively managed. So what defines a disciplined handoff between office teams and field crews?

Russell Treat: That’s a great question. That handoff implies a couple of things. One, we need to understand what “concluded” means — what that looks like. We need to understand what we’re asking of the person we’re handing off to, and what they need in order to be successful. A good example would be: we saw something going on in the right of way, it looks like an encroachment, I want you to go out and look at it. Obviously they’re going to need a location and whatever data caused the action to be taken. And then there should be a specific action they’re being asked to take. And then there has to be a way to come back afterward and analyze performance over time — particularly when you’re doing something that’s a new process, because you need to refine it. You won’t get it optimal the first time.

Mike Radich: Right, so we learn from what we do in the field and you’re always adjusting. So I think we could say some people struggle to do this. What differentiates organizations that consistently execute from those that struggle?

Russell Treat: I think organizations that do well have a few things in place. One is they really understand their policy, their process, and their procedures around how they’re deploying the technology. They understand ownership of scheduling, ownership of action, and ownership of outcome. And then they have a mechanism to come back and evaluate performance — not just “am I getting the data, am I getting the action done?” but “is this action at this cost warranted? Is there a better way to do it?”

Mike Radich: And that kind of leads to my next question. I feel like with execution, it’s only complete when it’s verified and documented. So what would a true closed-loop process look like?

Russell Treat: I think you could use PHMSA language on this: verifiable, traceable, and complete. Your records need to be verifiable, traceable, and complete. When you look at this kind of process and take it under the scope of pipeline safety management systems, it falls right into that frame. I’ve got to have records. They need to be verifiable — who created the record, who approved the record, who did the work, who approved the work. They need to be traceable — I need to know it originated here, went to here, went to here. And they need to be complete — whatever is required of the job is fully documented — because without that I don’t have the ability to do performance improvement. Pipeline safety management is all about getting things to a state where you can do after-action analysis to improve and improve.

Mike Radich: How do you feel operators confirm that everything’s been identified and that what has been identified has been mitigated? What actions would be taken to make sure everything is done correctly?

Russell Treat: That’s highly dependent on the particular process and the tools you’re using. But fundamentally, I think there has to be some kind of after-action verification that things are all correct. I think one of the things that’s going on in pipelining — and this is a much bigger conversation, and if you go to the conferences you’ll hear people talk about this — is that we’re moving from an era of “we had smart, well-trained guys trying to do the right thing” to an era of “we have smart guys, qualified to do the right thing, and documenting what they’re doing, and then other people analyzing it.” That is a state change for our business. But if we’re going to continue to improve our safety performance, that’s what’s going to be required.

Mike Radich: And I think it’s more change to the process. With all the digitalization in the world, it’s become more documentation-focused rather than just having a person look at it. So how do you feel like that’s changed your view overall? Because I know change is tough for a lot of operations and businesses and operators. How do you approach changing the process with new technology?

Russell Treat: That’s a really excellent question. Prior to 2010, I was doing a lot of SCADA projects, a lot of pipeline data projects, and I thought we were pretty good. Then in 2007, I heard about this new rule working its way through PHMSA called the Control Room Management rule — and I’m thinking, “Control room management? What’s that?” I went and found a couple of subject matter experts and went to school. One was a guy named Doug Rothenberg, who was an expert in alarm management. The other was a guy by the name of Ian Nimmo, who was an expert in what’s called high performance HMI. I went to all their trainings and workshops, had workshops done for our customers, and started building that into our projects. And that whole domain of human factor science just opened up a whole different awareness for me.

I think one of the things is that we are getting to an age where software is proliferating. With AI and some of the tools out there, things that used to take six months we can do in six hours — it’s just nuts. But none of that stuff takes into account human factor science. What does the human being need in order to optimize the process? Because I don’t believe that AI is ever going to replace humans. I do think it’s going to change the nature of work — just like the internet, and computers, and engines changed the nature of work — but it’s not going to eliminate human beings. So fundamentally, with any of these systems where we’re continuing to deal with more information and more digitalization, we have to start taking into account what does the human need in order to make the human decision, and how do we get that to them in a way that works? That’s called human factor science. And what we’ve been learning in the last fifteen to twenty years is that it is critical. There’s a lot more we can do in that domain, and most of the industry is way behind. There’s been a presumption that if I just get the data to the right person, they’ll do the right thing. And we’re getting to a point where that’s not only problematic — it’s becoming patently untrue.

Mike Radich: Yeah. And I think a lot of automation and the technology out there has helped — like you said, taking something from six weeks to six days. But that’s where this process comes into place, right? Being able to effectively have a workflow is vital. And I think the misconception with AI is that it’s looking to replace people. It’s actually just another tool to help you and give you more data. At the end of the day, we need to know how to process that data and make it effective. It’s definitely not going to replace the human, because at the end of the day, the human is out there doing the work.

Russell Treat: Right. I mean, it’s ultimately going to be up to humans to manage all of this.

Mike Radich: And just having that good workflow — that’s kind of what strengthens this conversation — use it as a helping tool. So I think the next topic we want to go to is the control room operations and what lessons we can learn from there. Control rooms operate under strict governance and procedural discipline. So what control room principles translate most directly to right-of-way and damage prevention workflows?

Russell Treat: Well, I think we’ve kind of talked about that already. One is the idea of situation management. The other is alarm management. Those two things translate directly. Situation management being: what does the person processing the data need to see to understand what’s going on with the right of way? And is it normal, abnormal, or emergency? That’s one. And then the other is: how do I work the data flow in order to have the data flow prioritize the work for the person doing the after-action once that data is being collected and processed?

Mike Radich: That definitely makes sense and helps it be more effective. As monitoring becomes more continuous and data-rich, what operational disciplines become non-negotiable?

Russell Treat: That’s a really good question, Mike — I’m only saying that because I need time to think about my answer. The really critical thing with any of this is: how do you boil it down to what the human needs to see? How do you give them an overview — like, working in the data, you can pretty much do whatever you need to do. But how do you give them an overview of where they’re at relative to where they want to be? That, I think, is the hardest part and the non-negotiable.

Mike Radich: And I would agree with that. We still have to do the processes, and it’s just about how you effectively utilize the data and move it forward. More data is coming. It’s up to us to create workflows and processes so that we as humans can understand it.

Russell Treat: Well, and I would also assert this: one of the challenges with AI is it’s going to generate distilled data, and it’s not always going to distill it in a meaningful way. That’s going to be really challenging. Because now not only do I have to wade through a whole bunch of raw data that I know is accurate but don’t know what it means — now I’ve got to wade through something that’s been through all that data and is trying to tell me what it means. And it may not be right. And that’s a whole different way of thinking about these data streams.

Mike Radich: And I think that ties back to why humans can’t be replaced, right? Because with that in mind, the data is not always accurate and doesn’t see the whole picture, because every situation is different. Being able to utilize the data as a helping asset rather than as something that replaces you — that’s the right way to look at it.

Russell Treat: Yeah. Actually, it brings up an interesting question: do we need to start thinking about what’s raw data, and then come up with a name that becomes part of our lexicon for that data that’s been through an algorithm and comes out the other side, but we don’t know whether to trust it yet? Whatever that is. That’s a really interesting question.

Mike Radich: Yeah, for sure. We’re going to get more data, and we’re going to get more of this stuff that’s been run through an algorithm. I don’t like the word AI. I think that’s a marketing buzzword. It’s algorithm. We got data that’s been run through an algorithm, and if we don’t understand what that algorithm is doing and what its strengths and limitations are, we don’t know what to do with the output.

Russell Treat: Right. And I think that speaks to what you said earlier about adjusting. With any new data that comes through, it’s always important to review your processes and make sure that when you’re adding something new, you’re ready to pivot and adjust. It’s still a newer technology. The human still has to utilize their brain and get through everything. It’s just another tool.

Mike Radich: So that’s actually all the questions I had for you. Is there anything else you’d like to share?

Russell Treat: Well, I think what’s going on in this domain — particularly with the satellite imagery and the opportunity to have near real-time data about what’s going on physically on the right of way — is really compelling. It has a huge opportunity to make a meaningful change in safety performance. If you look at gas pipelines, and in particular gas utility pipelines, one of their biggest risks is third-party damage. So if I have the ability to know immediately when somebody enters my right of way, and I know they were not approved to enter my right of way — that’s really valuable. And then that raises a whole bunch of questions about: well, I know they’re there, but what do I do about it? How do I respond in a meaningful way? Because I still have to send somebody out there to address it.

Mike Radich: And that’s part of the learning process, right? That would be defined as a critical instance, and then you’d have that process in play. It means you need to connect your image gathering and analysis to whatever you’re doing for one-call marking — your whole 811 marking process. You need to connect those things.

Russell Treat: Yeah. Because the issue is not about gathering data and putting it in front of the right people. The issue is about collecting information that’s actionable, one hundred percent. The imagery is part of that, but there’s probably other things that go into it if we’re really going to get to the value we’re striving for.

Mike Radich: And just like we mentioned — humans are needed, but they also cause a lot of the third-party interactions. So I think the thing to say about all of this is: we’re not running out of interesting problems.

Russell Treat: For sure.

Mike Radich: And it could be a nice way to educate people about the process to make sure everything is up to speed, and no catastrophe happens from that. So hopefully we can make this a safer and more educated place to be, so we have no incidents. That’s the end goal from all of this.

Russell Treat: Absolutely. That’s the end goal. And when we do have an incident — minimize the consequences.

Mike Radich: Yeah. Because they’re still going to happen, unfortunately. But to make it like you said, where it’s not critical — we can make them exceedingly rare. And this is actually a very interesting problem in our business. Pipeline incidents are exceedingly rare, which means I could come to work in the pipeline business, work my whole career, and never see an incident. Which means that when we do have one, we need to share it and learn from it. And whenever we’re introducing a new process or new technology, we’re always raising our risk early in order to lower our risk later, because there’s risk that’s introduced just in the learning. So there will be no shortage of interesting problems for us to solve.

Mike Radich: For sure. Well, hopefully with everybody out here, we can help minimize those and make them very, very rare going forward and make this a safer place to live. I appreciate your time today. Thank you. It was very knowledgeable and it was great to speak with you.

Russell Treat: Thank you. I enjoyed it. Have a great day.

Mike Radich: You too.

Russell Treat: I hope you enjoyed this week’s episode of the Pipeliners Podcast and the conversation with Mike. Just a reminder, you should register to win our customized Pipeliners Podcast Yeti tumbler. Simply visit pipelinepodcastnetwork.com and enter yourself in the drawing. If you have ideas, questions, or topics you’d be interested in, or if you would like to be a guest, please let me know on the Contact Us page at pipelinepodcastnetwork.com, or reach out to me on LinkedIn. Thanks for listening. I’ll talk to you next week.