In this episode of the Pipeliners Podcast, host Russel Treat welcomes back Mallory Gill to explore the intricacies of Management of Change (MOC) systems in pipeline operations. Together, they examine the nuances of departmental versus enterprise MOCs, emphasizing their respective roles, benefits, and challenges in risk management.

The conversation highlights practical insights from industry feedback, regulatory implications, and the importance of empowering change agents to create a more effective and streamlined MOC process.

Thinking through an Effective MOC System Show Notes, Links, and Insider Terms

• Mallory Gill is a Sr. Regulatory Analyst with EnerSys Corporation. Connect with Mallory on LinkedIn.
  • EnerSys Corporation is a frequent sponsor of the Pipeliners Podcast. Find out more about how EnerSys supports the pipeline control room through compliance, audit readiness, and control room management through the POEMS Control Room Management (CRM Suite) software suite.
• Russel Treat is the CEO of EnerACT Energy Services, as well as the host of the Pipeliners Podcast and the founder of the Pipeline Podcast Network. Connect with Russel on LinkedIn.
  • EnerACT Energy Services is a holding company of oil and gas technology and service companies. EnerSys Corporation is a frequent sponsor of the Pipeliners Podcast. Find out more about how EnerSys supports the pipeline control room through compliance, audit readiness, and control room management through the POEMS Control Room Management (CRM Suite) software suite.
• MOC (Management Of Change) focuses on planning the processes in a system, the type and quality of changes required, the risks associated with the plan for change, and the people that will be impacted by the change so that it is clearly communicated to stakeholders.
  • Departmental MOC: A localized MOC process focused on specific departments, allowing for tailored change management within smaller operational scopes.
  • Enterprise MOC: A comprehensive MOC system applied across the entire organization, promoting standardized practices and consistency in change management.
• O&M (Operation & Maintenance) is a comprehensive approach to performing pipeline tasks related to the operation and maintenance of gas and liquid pipeline systems. A robust O&M program provides personnel with the knowledge and understanding of each situation to enable them to correctly assess the situation and take corrective action.
• API (American Petroleum Institute) represents all segments of America’s natural gas and oil industry. API has developed more than 700 standards to enhance operational and environmental safety, efficiency, and sustainability.
• DIMP (Distribution Integrity Management Program) activities are focused on obtaining and evaluating information related to the distribution system that is critical for a risk-based, proactive integrity management program that involves programmatically remediating risks.
• Change Agents: Individuals or teams responsible for initiating, implementing, and managing changes within an organization, ensuring alignment with MOC processes and objectives.
• PHMSA (Pipeline and Hazardous Materials Safety Administration): The U.S. regulatory agency overseeing the safety of pipeline systems and hazardous materials transportation, setting standards relevant to MOC practices.
• Feedback Loops: Processes for capturing, analyzing, and integrating input from industry experiences or audits to improve MOC systems.
• PHMSA (Pipeline and Hazardous Materials Safety Administration) is responsible for providing pipeline safety oversight through regulatory rulemaking, NTSB recommendations, and other important functions to protect people and the environment through the safe transportation of energy and other hazardous materials.
• Operational Qualification (OQ) involves testing the equipment to confirm that it operates as intended, within operating ranges approved by the manufacturer. This process must be performed after installation, significant maintenance or modifications, or as part of scheduled quality assurance testing.
• OQ (The Operator Qualification Rule) refers to the 49 CFR Parts 192 and 195 requirements for pipeline operators to develop a qualification program to evaluate an individual’s ability to react to abnormal operating conditions (AOCs) that may occur while performing tasks.

Thinking through an Effective MOC System Full Episode Transcript

Russel Treat: Welcome to the “Pipeliners Podcast,” episode 365, sponsored by EnerSys Corporation, providers of POEMS, the Pipeline Operations Excellence Management System, operations and compliance software for the pipeline operator to address safety program management, control room management, and field operations. Find out more about POEMS at enersyscorp.com.

[background music]

Announcer: The Pipeliners Podcast, where professionals, bubba geeks, and industry insiders share their knowledge and experience about technology, projects, and pipeline operations.

Now your host, Russel Treat.

Russel: Thanks for listening to the Pipeliners Podcast. I appreciate you taking the time. To show the appreciation, we give away a customized YETI tumbler to one listener every episode. This week, our winner is V Prentice with Insight M. Congratulations V, your YETI is on its way. To learn how you can win this price, stick around till the end of the episode.

This week, Mallory Gill returns to the podcast as I follow up on a conversation of a few weeks ago about management of change and Mallory and I think through an effective MOC System. Hey Mallory, welcome back to the Pipeliners Podcast.

Mallory Gill: Hey Russell, thanks for having me again.

Russel: How many is this for you? Is this number four or number five?

Mallory: I think four.

Russel: We’re getting ready. If we do a couple more, we’ll pass Ross, so then you can hold that over his head.

Mallory: [laughs] There you go. You should have just turned it into a competition from the get go. I would have been on this every week.

Russel: [laughs] That’s awesome. I don’t know if the listeners, if this makes sense, but Mallory and Ross and I work together. Ross has been on the podcast many times to talk about control room management and related issues.

Mallory comes on and talks about safety issues. Anyway, so we have a lot of fun picking on one another here on our team. Mallory, thanks for coming back.

Mallory: Thank you.

Russel: I’ve asked you to come back to talk about management of change. I did an episode I don’t know, maybe six weeks ago now. I put a couple of things out there and I said, “Well…”

I really wanted to hear back from industry about what were the thoughts about the need for an enterprise management of change system versus the need for a departmental management of change system.

I made some points about how departmental systems are maybe more specific to the problem they’re managing, like SCADA versus integrity management versus a process or a document, a procedure, versus enterprise change.

I got a couple of people to respond. I’m not going to use their names. They were very generous to provide some feedback. They didn’t say not to, but they didn’t say I could. I don’t want to call anybody out and get them in trouble.

One of the responses I got back was departmental versus enterprise is shortsighted. People do not know what they don’t know. Systems may be fit for purpose, but risk assessment is critical. I’m paraphrasing there a little bit. I think that’s right. My first question is, would you agree with that?

Mallory: There’s a bit too unpack there. I don’t agree with the blanket statement that departmental MOCs are shortsighted. For instance, with the control room MOCs, I think that they’re a necessary interim step until enterprise MOCs become, I would say, thorough enough that we’re ensuring all of these activities that are required and all the risk assessments are being completed.

Really, I think the departmental MOCs have value, in that it ensures departmental-specific activities are completed. For control rooms, there’s 1165 verifications for SCADA changes that need to occur, point-to-point verifications, alarm rationalization. There may even be departmental-specific risk that needs to be evaluated and department-specific policies and procedures that need to be assessed.

I think there’s a level of detail and nuance that the departmental MOC allows us to capture, that maybe, if we were just utilizing an enterprise-wide MOC system, we might be missing out on some of those required activities in order to keep the process moving.

Russel: I hear you, for sure. That’s certainly something that’s been up for me as I think about this. I made the point in the previous podcast that there are certain changes that are so small and so confined within the department, they really don’t have outside-of-the-department risks. The point that was made, the response was, “Yeah, but you don’t know what you don’t know.”

And that is true. That is definitely true from a risk management standpoint. There are needs to do things that are unique within a department, but there’s also a need to manage that risk at a corporate level.

I got another response, and this one was actually quite thorough. The gentleman was very kind. He shared his previous experience and he broke the process down. For anybody who’s familiar with process safety management, which is the OSHA program that applies to plants, they talk about this in their MOC process.

What he said they did that worked very well is that they built MOC as a bottom-up approach, meaning, I want the people closest to the work to be able to submit the MOC. I’m a big advocate of that. I think that’s where you’re going to find the most opportunity to gain efficiencies, gain safety, is from the people actually doing the work.

Versus it being an engineering analytical process, it’s really more, “Hey, we could do this better if…” The people actually doing the work is where the ideas ought to come from. That’s across whatever work’s being done. That was one thing. That’s a little different than what we’ve talked about so far, I think.

Mallory: Yeah, I would think so. It typically takes the reverse approach where there’s a regulation. For pipelining, we’re evolving with MOCs, like in the chemical and in the plant space, management of changes, old news. We have a lot of experience in those areas in, PSM.

Now we’re seeing it in control room management, in those regs, TIMP and now DIMP with the NPRM. There’s more emphasis on management of change. Regulation initiates corporate movement to create a management of change process.

That takes a trickle-down, [laughs] if you will, approach to then incorporating feedback from the boots on the ground. I definitely agree that if we just reverse our philosophy there and start with empowering the change agents, the people who do the work.

Russel: Yeah. That’s well said.

Mallory: I do want to go back to your previous question of departmental versus enterprise MOC.

I think just because the MOC is in its infancy in pipelining — I’ll make that assertion with the asterisk, that some programs are pretty advanced with their MOC — but that while it’s in its infancy in pipelining, creating departmental MOCs are just a way…I would say they’re a short-term solution. They’re not the ultimate end goal.

Ultimately we want an MOC solution that’s pretty universally adopted, that supports all safety programs and this risk assessment company-wide. That fits into pipeline safety management systems seamlessly.

Russel: I think that’s a very important point, is there’s a distinction between doing something for MOC to meet a regulatory requirement versus doing something around MOC to meet the intent of pipeline safety management. Those are different questions we’re attempting to answer.

Mallory: Definitely. With my background, I started in the control room regulatory scope. Change management, slightly different than management of change, but the concept makes a lot of sense. To me, it’s a very intuitive approach. We’re justifying the reason that we’re making change. We’re tracking change.

I’m compliance and process-minded. It just makes a lot of sense to me that we would have a mechanism like that in place to keep track of that type of thing. At a company level, if that’s the intent then that’s ideal that we’re not separating that out and siloing that kind of activity.

Russel: Yeah. The other thing that was provided in the gentleman that kind of laid out the process that he was familiar with, his first thing he said, it was the origination was people doing the work or the term you use — change agent — he used that term.

He said that it could be a process engineer, a maintenance engineer, a project manager, an area manager, but most often it was engineers and technicians with one to five years’ experience that were driving the MOCs.

Which is interesting to me. It’s not the more mature people, the more senior people. It’s more the new people that are learning because they’re going to see things in a different way. Then the next step was to get the right people to look at those things and do some kind of, I would call it triage, to see what is the process safety impact of that change.

What they did is they landed that on the change agent. The person putting it in was responsible for saying, this is the process safety impact. They’re not only saying, “Hey, we need to change this,” but here’s why. Here’s the benefit, right?

Mallory: That’s interesting.

Russel: Yes. They’re not necessarily getting to how to make the change or maybe even the details of the change, but here’s what needs to change and here’s why safety benefit. Here’s the value, right?

Mallory: Which I would think would be a necessary data point. Anytime somebody wants to initiate a change in the organization, right? Providing a justification for the benefit and the safety impact. Is that incorporated into…How is that information incorporated into risk assessments? Because that’s like a qualitative…

Russel: Yeah. We got to get to that. That’s a great question. We got to get to that. My takeaway from this part of the conversation, and it goes back to what I was talking about in the previous podcast is, one of the resistance points related to enterprise management of change is the administrative burden of doing all the things you have to do.

What you have to really do is think about how does that process work? If I have a change request coming from a change agent and they’re saying this is what needs to change and this is the safety impact of that change, and this is how it impacts our process safety information or our process safety description, right?

That actually offloads versus, “Hey, I think we ought to change this.” It goes to somebody and then they’ve got to go back and say why are you proposing this change? You see what I’m saying? It offloads some of the administrative overhead by having the originator be responsible for that.

Mallory: I feel like we’re getting closer to a philosophy. I can’t quite articulate it, but there’s something there about maybe buy in of the person who initiates the change. We’re calling that the change agent. We’re empowering them in the workspace, right?

Not only can they make the request change, but also justify it and part of the process that’s been established is that the organization has to listen to and respond to their justification for the change in their own words.

Russel: The next thing that they required of the change agent is scoping. The change agent was responsible for…They would create the MOC and the system they use for recording. Think an SAP or a Maximo or something like that.

Then that took the MOC and it tagged it to an asset or an asset class or something like that, and then would keep it for historical recording, which is important. Once that’s done, then they would do a safety design review. That’s the risk assessment.

The change agent is saying, “Here’s the change I want to make, here is the impact on process safety. Here’s the asset or asset class it’s related to, and here’s the documentation.” The change agent does the full submission.

Then from there, it goes to a safety design review or a risk assessment to, is it feasible? Then it would get routed to the various technical crews depending on what it is. Electrical instrumentation, rotating equipment, fixed equipment, process operations, all that kind of thing. The risk assessment process is where that occurred. Who needs to look at this?

Where I get a little bound up is if I want to make a simple change in the HMI that’s only going to the controller’s workstation, how much of that risk assessment do I really need to do? Do I need everything that…If I’m the change agent because I’m the console and I submit that, how does that work?

That’s the part where I get bound up because I think that’s something that could be easily cause a lot of thrashing, just people saying, “No, it doesn’t impact me.”

Mallory: I mean, that’s the question, right? Because what’s the line between going back to, as always, the intent of this kind of change tracking mechanism is to ensure that things aren’t happening that introduce risk. That the next controller doesn’t walk in for their shift and assume the console and not realize or know that a change has occurred and that impacts their situational awareness, right?

The goal is always to operate safely, but there is a kind of line there between administrative burden and operating safely and efficiently. I do think there’s opportunity in like a good management of change process would have ideally some structure and qualification that eliminates a lot of that administrative burden.

I think of qualifying checklists. If we fall into these certain scenarios or criteria, criterion or whatever that would eliminate…Trying to figure out how to articulate this.

Russel: What you’re saying is, if I can structure the risk assessment in a way that I quickly, easily, and reliably eliminate those who are not impacted by the change, that I can get the change process down to only those impacted, that becomes an enabler. That adds value to the process.

Mallory: Yes. Enabler is an interesting and important word, I think, because you want to create a process that isn’t a burden to use. You don’t want to create a process that is so difficult to manage that people then don’t initiate change, they just perform the change without going through the proper channels.

Russel: Or we don’t make change because it’s too complicated.

Mallory: Yes. That too.

Russel: I would call that friction or resistance. I don’t necessarily mean people are opposed to it, it’s just that the administrative burden becomes friction or resistance to the process overall.

Mallory: Well, and we want to make sure that we’re only incorporating the necessary people into the change because everyone’s time is valuable. That’s an efficient, safe system is people are only focusing on what they need to be focusing on, and they’re not getting dragged into change conversations that don’t impact them.

Russel: I think that’s absolutely right. The idea of a safety design review and staging that where the first part of the review is, well, who’s impacted by this change? Then the second part of the review is for those impacted, what are the impacts?

Making that process a structured process and a controlled process so that I have history, because over time, I’m going to learn and I’m going to find, well, for this kind of process, we didn’t think this guy was impacted, but in actuality, they are.

Mallory: Right. That speaks to the importance of qualifying questions and creating a structure where the change agent inputs known data.

We’re not expecting change agents to be able to identify who’s impacted, but they’re putting in, “Hey, I want to adjust this procedure, this section of this document, or this process that we follow,” and then creating a system that’s intuitive enough to say, “These are the people that are impacted by that. These are the departments you have to weigh in on it.”

Russel: That is really where a big part of the value as effective MOC comes is understanding those impacts and risks, particularly who is and who isn’t impacted.

Mallory: This was a big topic of conversation at the Fall AGA and the PSMS workshop. MOC seemed like a shift from spring to fall, where it became that MOC was the solution to implementing effective safety management systems.

Russel: It’s a big part of it. The first part of it is just defining the system, and then I have to have a mechanism for making changes to it that doesn’t increase risk, [laughs] and that’s what MOC is all about. The last step that they had in here was what they called evaluation.

The last step, and I’m going to read pretty closely what was sent in, but if the hazards could be managed within the company’s risk profile without eroding project drivers to an unappetizing level, then it would move forward.

Project drivers would be things like, “We’ve got to move the product, so if I’m going to do something that’s going to limit our ability to move the product and it’s going to do that in a way that has a cost that’s unacceptable,” that kind of thing. The evaluation is, “How much risk are we going to reduce, and what’s the impact on operations to reduce that risk?”

Once they got through all that, then they could go about executing the MOC process, actually making the change, engineering and making the change. Three critical steps, orientation…I’d say it’s four steps. It’s orientation, scoping, safety review, and evaluation.

Mallory: In the evaluation stage, that’s where you’re talking about cost-benefit analysis?

Russel: Not necessarily cost-benefit analysis, but it would be risk reduction versus cost of risk reduction.

Mallory: These are four steps just to determine if the MOC is going to move past the initiation stage into the implementation?

Russel: Correct. Frankly, that’s the part of MOC that…I appreciate the gentleman submitting all this information, because it helped clarify for me the process. Given some other work I’m doing at the moment, it resonated around what MOC looks like for PSM.

It’s like, this is a process, I think, could be pretty universally understood. The tricky part of the process, to my mind, is the safety design review.

Mallory: Say more about that. Why do you think that’s the tricky part?

Russel: Because that’s the part where you could thrash people if you’re not careful. One of the comments I remember from the Spring AGA and the MOC things I went to was somebody implemented an enterprise MOC process, and every single thing that got originated, they put a bunch of people on a distribution list and said, “Are you impacted by this?”

Because of that, many of them were spending a lot of time just saying, “No, no, no.”

Mallory: Right…

[crosstalk]

Russel: Creating an administrative burden for the departments.

Mallory: Right, so the stress was put on the organization rather than creating a process that could determine that intuitively.

Russel: They created a process, but the process had to have an administrative burden. I don’t know that you can do that intuitively. You may be able to do it programmatically. I want to pivot a little bit, because this gets very interesting.

I did an episode, I don’t remember it, but if you search the website for airline safety, you’ll find it. We had a gentleman come on who had 30 years in the airline industry and had been involved in airline safety since its inception. He was a pilot.

He said that the way that this works in the airline industry is they have a system for triaging these requests. They typically will come from typical groups. I might have submissions from pilots, flight attendants, ground crews, luggage crews, maintenance technicians.

You might subdivide that maintenance into avionics, hydraulics, engines, that sort of thing. Anything that was submitted would go to a group that had that expertise and would do that safety review. They would work that MOC evaluation process to determine, should we execute this or not?

Because it went to a group, they had some seniority there, and they had knowledge of all the submissions, and has this been submitted before, who does this impact?

They basically created groups that would triage that, and then set rules about, once something was submitted, how fast they had to get to it and how feedback was given to the originator. What you have to think about is, because I have to have the human experience in the process.

Mallory: Absolutely.

Russel: That’s where if I have the right humans in the process and I’m giving them the right data, then the intuition will add value. If I have the wrong humans in the process or I don’t give them the right data, then I’m going to become an administrative burden.

Mallory: That’s a fear, too, right? Philosophically, we need accountability when we implement change. If we are not intentional about who we solicit for input on change, then how are we effectively managing that change?

Russel: I’m going to make an assertion here. Again, I’m going to ask listeners if they’re so inclined to comment on this because it’s really, really helpful to facilitate this conversation. I think a lot of pipeline operators are working through this right now.

What I’m going to advocate, noodle, is that, one, we need to make it really easy for people to originate change. Two, we probably need to create a triage capability that’s departmental.

I’d have a triage capability for corrosion, for integrity, for control room, etc. Then the group that’s triaging those requests, those MOC submissions, they would be the ones that would be responsible for building the questionnaire or the process for determining what the safety impacts were and how that MOC needed to be dealt with.

Mallory: I have a question for you. What’s the correct level of software versus human evaluation? I’ll give you a specific example. A change agent says or identifies what they think is a required change.

Do you think that in a good MOC system that there would be a vetting process built into, say, the request process that eliminates non-viable change requirements? Or should all initiated changes be going through this triage process to determine viability? Because I’m going back…

[crosstalk]

Russel: I think all changes. The only thing that wouldn’t go through this process is something that is a direct replacement. It’s a repair. I have something that’s broken and I fix it following a standard policy, using a standard part. Anything else would go through this process.

Mallory: In this process, you’re saying, change agent identifies required change, that always goes to a group of human beings who triage that and determine viability?

Russel: Yeah. It might be a little bit more complex than that, but I want to try and answer the question and paint a picture. What I’m doing here is a bit of visioning. The submission ought to be able to be something I can do from a web page or from my smartphone or a tablet. I fill out a form it, I put in all the required information, and I say, “Submit.”

Then that would become a initiating record. That record would go to a triage group, and then they would look at that and say…I think the triage is probably a little bit more involved because if you have a really healthy system, you’re going to get a lot of change requests. That what you’re looking for. You want people to very proactively and energetically submit ideas.

Which means you should get some ideas that are the same or very similar. Part of the triage process should be, “Hey, I’m getting this request from multiple people across the company. That must be something we really need to focus on.” It’s not just a request and process it, but are there multiple requests and all that needs to be rolled into a single change?

Mallory: Where my mind always goes is — well, I’m in conversation with myself on this — but my mind goes to, in a healthy system, change agents say, “Here’s a potential required change.” As you’re saying, in a healthy system, we’re getting a lot of that. Not all of those submissions are going to lead to implementation, right?

Russel: Right. Absolutely.

Mallory: My thought is, what can we develop…? Almost like the questionnaire concept. How can we vet some of this in the origination of the request so that it’s triaged appropriately from, “Hey, this is a viable change,” to, “Hey, maybe this is actually just an indication that we need to double down on retraining efforts.”

Russel: Right. No, no, it’s a really good question. It’s a really good question, Mallory. I think the answer is that coming out of that triage process would be as quickly as possible feedback to the originator.

Then as that process, as that request gets worked, you continue that feedback loop. It’s very important, if you’re going to keep that system healthy, to get the feedback back. I want to know I submitted a change, that it’s being worked, that people are looking at it, and what conclusion they came to and why.

Mallory: A great deal of transparency from the…

Russel: Yes.

Mallory: When we do that in safety observation and reporting, we refer to that as disposition and resolution. Being able to track the full lifecycle of a request, especially if it’s pertaining to the safety of how you’re operating. Also, that it empowers that change agent and makes them feel heard, and promotes trust between boots on the ground and management.

Russel: If you have a healthy system, it should be feeding a lot of recommendations. There should be a triage process that is providing feedback. In fact, the entire MOC process should provide feedback to the originator.

Then potential outcomes could be, “We’ve had these 15 requests. They’re all really the same request. They’re going into this one MOC.” Or it could be, “This one request is going to this one MOC. It’s low impact and it can be executed in this department.” Or it could be, “Well. that’s not really an MOC, what that is, is we need to look at competencies and training.”

Mallory: Do you think, I’m reversing that?

Russel: It could be a modification to the training program too. Right?

Mallory: Right. Maybe the analysis of an initiated change indicates not that a change needs to be made in the operating practice, but that we’re not effectively training our people to follow that process. Question or conversation point. In a perfect world, what department, who owns the MOC process?

If we can step back from the regulatory impetus because I have an opinion that MOC really should be a component of pipeline safety management systems and that it should touch all departments enterprise wide.

Russel: I believe I agree with you, and I would say that philosophically this is what I would assert subject to my mind changing as I get new information. [laughs] What I would assert is that pipeline safety management compliance and MOC should all exist in the same organization within the operator.

That organization should also have a internal inspection capability, so that I’m not only running those processes, but I have processes in place to analyze my performance around those processes. Now, that is a huge ask, and it’s a major rethink of how a lot of organizations are currently organized, but that would be my assertion.

Mallory: That’s interesting because when I think of…I don’t know if this is correct, but when I think of PSMS, I think of it as being separate and somewhat above all of the departments. It really needs to be [laughs] not pervasive, but compliance and PSMS and MOC, to me exists somewhat separately. I’m trying to think of how I want to justify that, but…

Russel: Well, I don’t know that, for the purpose of this conversation, you need to.

Mallory: I’m going down a rabbit hole.

Russel: I don’t know if it’s a rabbit hole. It’s a really valid question, but we’re going long here a little bit. I want to wrap this conversation up. First, thanks for doing this and just sitting here and having a free-flowing conversation.

These are the kind of conversations that we often have over a cocktail as we’re trying to figure out something or fix a problem. Hopefully, you, as listeners, enjoy listening to this kind of conversation. I certainly enjoy having them.

Again, if you have feedback on what we’re talking about or input, please provide it back. We’ll chew on it. We’ll get back on the podcast and come back and talk more. Who knows? Some listener might have the silver bullet for how to do MOC. If you do, please share.

Mallory: Thanks for having me, Russel.

Russel: Great to have you, Mallory. I hope you enjoyed this week’s episode of the Pipeliners Podcast and our conversation with Mallory. Just a reminder before you go, you should register to win our customized Pipeliners Podcast YETI tumbler. Simply visit pipelinepodcastnetwork.com/win and enter yourself in the drawing.

If you’d like to support the podcast, best way to do that is to leave a review. You can do that wherever you happen to listen.

[background music]

Russel: If you have ideas, questions, or topics you’d be interested in, please let me know. You can do that at the Contact Us page at pipelinepodcastnetwork.com, or reach out to me on LinkedIn. Thanks for listening. I’ll talk to you next week.

[music]