Welcome to the PIPELINERS podcast, Episode 162, 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 standards organization in 1919, API has developed more than 700 standards to enhance industry operations worldwide. Find out more about API at API.org. And now your host, Russell Treet.
Thanks for listening to the PIPELINERS podcast. I appreciate you taking the time and to show that appreciation we are giving away a customized Yeti Tumblr to one listener each episode. This week our winner is Frank O'Nesto with Burns-McDonald. Congratulations Frank, your Yeti's on its way.
To learn how you can win this signature prize back, stick around until the end of the episode. This week, David Miller, Director of Standards with API, joins us to talk about the API Standards Development Process. David, welcome to the PIPELINERS podcast. Thank you very much, I'm looking forward to the conversation.
Likewise, likewise, I'm really excited to have API involved with the podcast and I've been having conversations with you guys for a while about getting you to come on and talk about standards and I'm really excited about this. I think it's going to be awesome. Yeah, I'm looking forward to it. Standards is one of our foundational programs.
As the Director of the Standards program, you're probably not surprised. I never tire of talking about standards. Well, that's a good thing because the API has got a lot going on in that domain. Maybe David before we dive into it, could you give yourself a little bit of an introduction and tell the listeners a little bit about your background?
Yeah, I'm happy to do that. I'm a graduate of the University of Utah. I've lived in Texas most of my life growing up, but we moved out west when I was still in high school. I went to college out there, graduated with a degree in civil engineering and tried to find a job as soon as I could, then we'd give me back to Texas.
It turned out that I found a job in the oil industry, working for a wire line company out of Fort Worth, Texas. I moved back and did that for a while, worked in the old patches, we call it. They went back into engineering and used in Adalescent, ultimately joined API in 1985 and then moved up to DC in 1990. I've been there now, hard to believe, 35, 35 years involved in API's technical programs primarily in the standardization area.
Well, time certainly flies when you're having fun. It does. Tell us a little bit about the history of API and how API started and what is its background, how did API get started with standards? Sure, happy to do that.
API has been around a little over 100 years. In fact, we celebrated our Centennial last year. We were formed in 1919, really as an organization to work on three foundational programs. The first foundational program that the Institute was formed to work on was standards and standardization, because there was no common industry standards out there.
If you were drilling well and you needed some additional drill pipe, and the manufacturer you were working with wasn't available or couldn't provide that to you, and you went to a different manufacturer, sometimes the threads would match up. Obviously, that's not a good thing from a safety and interchangeability standpoint. Really, one of the foundational programs for the Institute was technical standards, and that's the group that I lead now. The second program that we took on that we're still doing was statistics.
There was no industry-wide excepted statistics. We now publish the weekly statistical bulletin that's been published for many, many years, and it is the most widely followed statistical bulletin that talks about industry statistics, production, refinery runs, things of that nature. We're continuing to do that. The last program that we started, and it's really a technical program when you think about it, it was working with the federal, state, and local governments on industry taxation issues, because there was just a wide variety of how industry was taxed, and there was a need to work with the regulators directly.
If you think about it, our foundation really ties into both technical work and industry advocacy work, if you will, from the standpoint of the taxation side. That's really how the Institute got stood up all those years ago. Interesting. David, what is the scope of standards that API addresses?
I don't think that's well understood. This is obviously the pipeline or podcast, but API is much broader than that. Yeah. As I said, we were formed in 1919 with standards being one of those foundational programs, and we published our first standard a few years after that in 1924.
It was on, as I mentioned earlier, on drill threads being an important issue for standards for safety and interchangeability. Since then, we've grown our standards program from that first standard to over 700 standards that really cover all of the segments of the supply chain for oil and natural gas. We're the only standards developing organization that is focused solely on oil and natural gas as an industry. Because of that, we developed standards, of course, and exploration and production.
We developed standards in pipeline and in measurement. So we produce standards on how you get it out of the ground, how you get it from where you need it to be to somewhere else. We produce standards on refinery processes and, of course, marketing and getting the end product to the end-user. So we have a little over, as I said, 700 standards that cover all the different aspects of the oil and natural gas industry.
So this is a question I think is interesting. So 700 standards and you're addressing everything basically from the reservoir to the end-user. That's correct. And how many gaps do you think you have?
This is something that we work with our members all the time. We have a series of governance committees that are made up of the top engineering managers within each of the disciplines that support our standards programs. And we look at the overall standards suite twice a year and really talk about where are the gaps? Where are the areas that we need to be developing new standards in?
So for example, what are the newer standards that we're working on in the area for exploration and production right now is on additive manufacturing or what we used to call 3D printing. Additive manufacturing is a new technology that I think has a tremendous opportunity to be a game changer for our industry. And I know that's a kind of a tired phrase, but if you think about it, a lot of the people that we operate here in the US and around the world are going to be remote. It's going to be difficult at times to get replacement parts there.
It's going to be difficult if you have equipment that's an install base that's been there a long time. And so the ability to create a series of standards for additive manufacturing where you can create those parts as you need them is really key. But that's an exploration of production. When I think about some of the new areas that we're working on in pipeline in particular, since of course this is the pipeline's podcast, so we should focus on that.
We just started a new project actually just in the last few weeks on a new standard on public engagement for pipelines. And really when you think about it, there's a full lifecycle of pipeline. You have your, when you initially decide where the pipeline's going to go, you have to work with the permitting side, you have to work with the communities, you have to work with a lot of different stakeholders. And of course that's extremely critical these days.
And so we're developing a standard working with a very balanced committee of individuals to say, well, some of those best practices that people should be following as you're looking to put these pipelines through these communities. Yeah, it's interesting. This is, I think this will be when it releases podcast 160 something. And I'm always amazed at how little I know about pipeline.
The domain of what I don't know just seems to be ever growing. And I think the interesting question about standards is technology evolves, the way we do the business evolves and the standards have to evolve along with that. Are there standards that you say 700, I would assume that's the act of how many standards have been legacyed or basically said no longer of use? Yeah, so we have a requirement, we'll get into this at some point.
I'm sure when we talk today about our standards review cycle and all of our standards in accordance with our accredited process have to be revised, reaffirmed, withdrawn every five years. So there's literally thousands of standards over the years that we've replaced with newer editions or newer technologies. I think if I go back into some of the older standards when I've done a bit of research on some of these topics, I'll find standards that we developed years ago on storage tanks made of wood, which told you how to design and properly install a tank made of wood because at the time that was a practice that was fairly commonly used in the more remote old fields. So probably literally thousands, I've never done a hard count.
That'd be an interesting project. Maybe I should look into that. Well, I do think it's kind of interesting to realize that not only are you creating new standards and revising standards you have, but you're also deliberately saying, you know we don't need to maintain this standard anymore. And that after a hundred years, that's got to be a pretty big number.
Yeah, we do take a very hard look at all the standards as they come up for the renewal cycle and determine what the appropriate next steps are with them because we recognize as valuable as they are, of course, they're a burden for industry to maintain. They're a burden for folks to keep active. So we always take a hard look at those and make sure that our suite is really meeting industries and needs and serving society in a way that provides that safe, reliable and sustainable energy that quite frankly the economy runs on. Yeah, exactly.
So how would you stake the core mission of the APIs that relates to standards? Yeah, so it's really easy. So the API mission is to promote safety across the industry globally and to influence public policy in support of the strong Bible, US oil and natural gas industry. And when you really focus on the first few words of that mission statement, promoting safety across the industry globally, you really can't do that without strong technical standards.
You really can't have safe operations if you don't have standards by which everybody can understand what the requirements are for the equipment, for interchangeability, for operations, for things of that nature. It reminds me of a comment I was thinking about the other day my father-in-law was a landman. And for those that don't know in the exploration and production field, that's the individual that puts together the various leases on the sites and works with the landowners and works with the regulators. And of course everything goes into putting in all the gas lease.
And when I told him I was joining an API, he said, well, the first time he had run into API was when he had gone out to a well site. He was checking on a project that he had put together with some other folks. And the foreman said, well, one of the things we check here is we want to make sure that everything's API. And he said, well, what do you mean?
He said, well, is everything API? Is everything on the well site meeting API standards? Are all the operations as safe as they need to be? And that always stuck with me.
That's how a lot of people in the old field see us. Is everything API? Does everything meet the standards that it needs to meet to make sure that we're operating in the safest manner possible? Yeah.
And I, you know, there's a, we could probably do a whole podcast just on that conversation right there, because I've certainly had the same experience. And more than one time somebody's asked me, well, is it compliant to API and they cited a standard and I didn't know that standard? Yeah. Yeah.
You're like, you know, for a vendor, you know, that happens. You're like, why do I not know what that's going on that standard? Exactly. You know, standards change and standards evolve.
And, you know, as you change your business, you change what you're doing, then, you know, the impact of those things modifies. Yeah, absolutely. Absolutely. So I want to ask you about the process.
So I know that as a standards organization, API is accredited. So maybe you can talk to us a little bit about what does it mean to be accredited and what does API have to do to be accredited in terms of its standards? Sure. Sure.
So we're accredited by the American National Standards Institute or ANSI. And ANSI's organization is actually a year older than API. It was formed a year before us in New York. And it is sort of the standards authority here in the United States.
It has a memorandum of understanding with the Department of Commerce National Institute of Standards and Technology. And one of the things that they do is they accredit voluntary consensus standards organizations like API. So you become an accredited standards developing organization or SDO through an ANSI process. And what that requires is that you follow their four pillars for consensus standards.
You need to have openness and openness for API means that, you know, anyone that has a direct and material interest in a standard has an opportunity to participate in the process and that our standards meetings, you know, with the exception of some of our policy groups or budget groups are, you know, broadly open to anyone that wants to participate. I want to underscore that. They go, sorry to interrupt you. I want to talk about that because API standards committees are open even to non API members.
So long as they have an interest in the standard. Yeah. The requirements to participate in an API standards development process committee is you have to have, you know, obviously technical competence in the subject matter. We need, you know, engineers that understand the subject matter being discussed and you need to have the ability to participate in the process.
And since we're a standards developing organization based in a trade association, you know, we tie everything back to the member companies or the company individually, whether you're a member or not, you have to have that management support. You have to have to say, right, you know, this is important to us for you to participate in this process. So we'll, we'll help you find time to do this work. So it's important work.
But yeah, openness is the first requirement. The second requirement is what's called balance. And what that means is that when you develop your standards, you have a balance of different interest categories working on the standard. You don't want just the operators or just the service and supplier manufacturers writing the standard.
You want to balance. And at API, we follow the, what's called the one third, one third, one third policy where, you know, we look for one third of the people around the table to be from the operators or the owner class, if you will, you know, the oil companies or the pipeline companies, depending on the standard. One third from service and supplier manufacturer, depending on the standard. Then one third is called general interest.
And that's pretty much everyone that's not in the other two classes, but increasingly that includes NGOs, that includes government representatives, that includes, well, in the case of the public engagement standard, you know, we have a lot of different interests there, of course, from, you know, from around the pipeline world. So that's a very open classification, includes your consulting engineers as well. So we really want to balance around the, around the table when writing these standards. From a consensus standpoint at API, we define consensus as meeting approval of any standards action.
And that's a revision or, you know, publication of a new standard to require two thirds majority. And at least 50% plus one or at least, you know, more than half of those who eligible to vote have voted. So that's our requirement for consensus. But we do all of our balloting, you know, of course, through an online electronic system now we used to, a lot of the folks that have been around a while will say, well, it's the document gone out for letter valid because literally when I started we would mail ballots and then they would come back in and we would count them and create spreadsheets.
Now of course, that's all electronic. So our returns are much higher and our approvals are much higher, but those are our minimums. And then finally, one part that's really important that I don't think everyone understands or appreciates is the due process. And what due process means is when you go in and you comment on an API standard, you know, whether you're a voter or a non-vote or whether you're a member of the committee or not.
And we have a website, a link on our website that's called all open ballots. So essentially everything that's open today, you could go to a comment on, we have a responsibility to provide feedback to each and every individual who provides a comment as to how their comment was treated and what the next steps in the process are. And for some of our standards, we'll literally have 1,200, 1,500, 2,000 comments on those really significant standards. And we do a very deliberate process of working with the committee leadership and the committee to consider each and every comment and then to provide a spreadsheet on how they were treated so that it's a very, very transparent process.
I can certainly affirm that David, as I have participated on a number of standards, rewrites and such, it is a very thorough, comprehensive, you know, deliberative process. And I think it makes it challenging sometimes too, because when you're writing a standard, you're trying to write a best practice, but you're trying to write it in a way that it works for everybody. Exactly. And that can often be a challenge in the level at which the words get discussed and parsed.
It's sometimes challenging. I find it interesting though, as opposed to other things that I've read technically, that generally I read an API standard and I understand what it's saying. That's good. That's our intent.
That's a small thing, right? Because these are a lot of these things are very technical. They're very technical documents. But yeah, so that's the first part of the ANSI accreditation.
But it's not enough for the ANSI accreditation for us to simply say that this is how we do our process, that it meets these four pillars of ANSI requirements of openness, balance, consensus and due process. ANSI then follows up with an audit. And so the API standards program is undergoing an audit actually. It's early next year.
It's on a five year cycle tied into the five year cycle for the revision review or re-appirmation of standards. So what we do is they'll come in and they'll select a sampling of all of the standards that have been published as American National Standards since the previous audit and then really do a deep dive on each one of those to make sure that we're following all of the things that we've got in our own procedures, that we're following all the ANSI criteria, and that we're making sure that when people reference or use these standards, they're comfortable to know, hey, they've really gone through this accredited process. I know I can trust the information in here that has been fully vetted by a group of experts and it really represents that industry gold standard or best practice. That's really, so every standard that API produces gets an ANSI audit at some point.
Now, what they'll do is they'll sample the standards that have been published as American National Standards since the previous audit. They can't obviously publish, review all of them. So for example, this year, we've just about closed out the year on publishing. We're right at 82 standards off-press this year.
Last year we had 90 standards and so we've been running roughly in that range for the last few years between 75 and 85 to 90 standards a year. So they'll do a sampling of the American National Standards and say, right, let's make sure that API is fully following this process. But whether it's an American National Standard or whether it's an API standard that's not been published as an ANSI, we still follow the same process. We still look at open-ness balance and consensus and due process and really make sure that we're following all those practices and procedures.
So that's 90 standards a year, give or take. Give or take, yep. And knowing the level of effort required to push one of those out, that is a huge amount of effort. It's a bit mind-boggling actually.
Yeah, we couldn't do it quite frankly. I mean, I obviously have a very dedicated team of standards engineers. Many of them have many years in the industry. Some, of course, are relatively new, like most organizations, you're always having some change.
But we really couldn't do this work without the 7,000 plus volunteers in our database. We have over 7,000 individuals who have been active on API standards committees over the years. And they represent a little bit over 2,200 different organizations around the world. And there's no way that we could do this work on around if we didn't have all those experts really working hard through all these standards, revision cycles and new standards to really help us produce these documents.
Yeah. And I would bet that probably some significant portion of that number, a third to a half, are spending anywhere from eight to 20 hours a month working on standards. Yeah. We recognize that it's an awful lot of work.
And so a number of years ago, we created a years of service of work program where we recognize all those volunteers that some of them may never for whatever reason, sort of become a task group or a work group or a subcommittee or committee leader. And so we recognize them every five years for their years of service. And to be honest, we've had some individuals between 45 and 50 years of service on API standards committees. I mean, they literally, when individual was explaining to me, he literally attended his first meeting with his father, who had also been in the oil and natural gas industry when he was in his late teens, early twenties, when he went into engineering and then joined the API standards committee and kept that tradition going.
So yeah, in our last meeting for our refining committee last fall in November, we did have one individual with 45 years of service on an API standards committee, which is just unbelievable. Yeah, it's amazing. It's amazing. Well, so I'll transition this here.
I can get spun out on that whole conversation. I think, you know, before I leave that, I think I will say this, I do think that reflects on just how committed the community is to improving how we operate. It really does demonstrate a significant commitment by all the players in this industry, both the operators and the vendors that they're putting their best engineers on these projects. Yeah, that's one of the other things that's always impressed me about working on these standards committees with these volunteers.
And you've probably seen it as well, Russell, in your work that because we're representing their companies, the company's really sinned. They're absolute top specialists in whatever field it is. And we're working on. So you, you know, one of the great things about working on the standards committees in addition to, you know, that sense of fulfillment of doing that good work is you really work with a lot of really smart people.
I mean, you walk out of the room a lot smarter than you walk in. If you know what I mean, just yeah, absolutely. That's one of the reasons I like doing the work is because of the learning is so, I mean, the learning is just, it's intense, but it's very rewarding because you're learning it from the best. You're learning about the state of the art.
You're learning what people are doing and why they're doing it that way because the conversations in these rooms are generally very open and very frank. Oh, yeah. Yeah. Well, you mentioned, you know, the commitment to safe operations, reliability and sustainability.
One of the API principles, I'll cite too, that ties directly into our mission statement is our principle to commit to enhance the integrity of operations across the industry by applying API standards, implementing workforce training programs and participating in performance initiatives. And so if you think about standards, they really are the foundation for a lot of this work that gets done to really raise the bar for everybody so that everyone's operating safer and with the best integrity that they can because it's very important for industries continuing licensed operate, then we demonstrate to the public and to the regulators and everybody that, hey, we're going to do our absolute debt level best to make sure that all these operations are safe and sustainable. And as we like to say that everybody goes home to their family at night. Absolutely.
Absolutely. So you mentioned regulatory community. How are API standards and PHMSA and the pipeline regulatory community? How are they alike and how are they different?
Yeah. So they're alike in the sense that we're all focused on safety. We're all focused on making sure, as I said a minute or so ago, that everyone goes home to their family at night. You know, the difference is that API standards and the use of API standards is entirely voluntary.
Unless somebody puts a minute regulation and will get to that in a minute or puts it in a contract or in a tender bit or something like that, their use is entirely voluntary. They're out there for industry to use, to take advantage of, to make sure that they're really meeting that gold standard. But beyond that, there's no requirement. The regulators, of course, create regulations.
And what regulations do is they do create, of course, a legal framework for how you need to operate. And because I think of the API's tradition of developing standards essentially since its formation, being formed as a standard setting body in many ways, and this very rigorous third party accredited and audited program that we go through, the regulators widely use the API standards. They're buying large to the most widely cited standards in the US and increasingly around the world in both federal, state, and international regulations because they're recognized really as that gold standard. And so the regulators use them quite extensively.
And of course, here in the United States, once a regulator puts an API standard incorporated by reference into the regulations, then that is the requirement that you must follow. And speaking about a recent experience we've had with this, we all remember the gas leak in Southern California, I think it's a LECO Canyon or LECO Canyon. Right. Right.
Right. Right. That's related to the gas storage facility. Exactly.
Exactly. Well, you know, API, again, working with our subject matter experts, they got great vision. And actually, you know, sometime before that incident occurred, we had just published two new standards on safe underground storage in these different kinds of caverns and facilities. And once PHMSA went through a very reviewed rulemaking process, went out for public notice and comment on the proposed rule, when they finally published the rule, the rule said, you know, the API standards and these happen to be 1170 and 1171, which are going through a revision cycle because they're coming up on their five years as well.
Anyway, in the final rule, they said, you know, this is how industry needs to manage these underground storage facilities. You need to follow API standard 1171, depending on the circumstance and the operation you have. So the app really shows you that the regulator is recognized, you know, the value of the data. We often encourage their participation.
Of course, their resource can train like everybody. We'd love to have more regulators at the table than sometimes we're able to get. But we do work very closely with the regulator so that they can understand the value and reference standards where it makes sense for them to do that. Well, certainly I've been involved in some standards committees where there was a regulator involved in sitting at the table and participating in the conversation.
And that's often quite interesting as well and informative. I'll just say that. So ultimately we're all trying to do the same thing. We're all trying to improve safety and improve performance.
Yeah. Yeah. Speaking of performance, I'll just mention that, you know, one of our policies and API and a practice that we follow is that we really want our standards to be performance-based, to the maximum extent they can be. What I mean by that is you can have performance-based standards and you can have prescriptive standards.
Prescriptive standards are often used, you know, sometimes in a manufacturing environment where, for example, you've got to have very specific tolerances, again, going back to that threading example, going back to a strength of materials example and pipe and other things. But then for operations, you really want to have performance standards. You want to tell people kind of what they need to do, not necessarily specifically how they have to do it. And really, we like to say that that way these standards really, you know, are more of a ceiling.
They're things that people can reach for and they can innovate and find different ways to do as opposed to what you might consider a floor, which would be an absolute, well, if I just do this, I mean, compliance with either the standard of regulation. We really want to create standards that are performance-based so that, you know, people are always innovating in thinking of ways that they can do things better and do things safer and more efficiently. Right, exactly. Well, you know, performance standards also require more thoughtfulness and that they're harder to write.
They're also, I think, sometimes harder for the community to understand. Well, that is absolutely true. But I will tell you that. You need to know the background for the standard.
Yes, yes. It's kind of standards. Yeah, but they're also in accordance with the government's thinking as well. There's a National Technology Transfer and Advancement Act, which encourages, actually requires really, the regulators to use industry consensus standards when it meets their missions.
But it also, they're, they only be put out a updated circular on implementation of the law and in the circulars background, it talks about performance versus prescriptive standards. And they do encourage performance standards because they recognize exactly the value that you've identified while they're harder to write. They are better in the sense that they really give that opportunity for innovation and improvement. Right.
So I was, one of the questions I had for me to ask was, why does it take so long to get a standard out? And I think we've kind of already answered that question, David. I think you've kind of covered that. Do you have anything you want to add to that?
Because I'm sure that's a question you get asked frequently as well. Yeah, it's a very salient question. It's an important question. It does take time to develop these standards because of the amount of work that goes into in the review process.
The checks and balances to make sure that all the different interests categories are considered. But one of the things that we started doing a number of years ago was we've gotten better with some of our electronic tools is one of our key performance indicators now is called our standards development cycle times. And we've been tracking this very, very, very closely for a number of years. And I'm happy to report that that this year for our 2020 off-press standards.
We're down about 12% from the time it took us to develop a standard from start to finish from 2019. So right now we're a little over two and three quarters of a year to develop a standard and that includes the time for project approval to publication date. And of course, the biggest amount of time there is what's called the pre-valid phase, which is really the consensus-building phase. I mean, as you've said, you said in some of those committee meetings, some of that can be pretty tough-sledding, but it does give you a great product at the end.
But we're all in the work. I think it's also driven by the complexity of the standard and how quickly the technology moves. You think about something like the cybersecurity standard, which is working its way through on the pipeline side, and how those guys can keep that kind of standard anywhere close to current and meaningful, is really challenging because it changes so fast. Exactly.
And we could not, in addition to the great leadership we've had from that group, we couldn't have done it if we weren't thinking about our standards from a performance-based approach. Exactly. That's exactly right. Yeah, you can never write every specific kind of requirement in cybersecurity.
And the other thing that's taken a little longer on that standard is we've moved it from sort of what was basic skated-type security, which is important enough to really the broad internet of things, cybersecurity. When you think about all the different threats that all of our systems are challenged with now, whether it's an over-and-act or an accidental act, like you walk onto the field site with your latest smartphone or gadget, and it's got something in there that you're not aware of, and all of a sudden it's talking to your systems, obviously there's a lot to protect it. Yeah. I think it's just a good illustration of why it takes the time it takes, because you've got to write these things in a way that they're going to make sense when they're published and have at least a five to ten-year lifecycle the way they're written.
Exactly. Exactly. Exactly. So, you really want to write a standard that's going to stand that test-applying.
So, there's quite a bit that goes into it. So, David, what do you think the future is related to API and its standards processes? Where's all this headed? What should people be looking for?
Yeah. I think what people should be looking for is as industry evolves, as we all work to kind of determine how we can be more efficient, more sustainable, more reliable, and in an ever-changing world, I think we're going to see standards in new areas. I've already mentioned a couple. Of course, we have the additive manufacturing on the downstream side.
We're doing a lot of work in risk-based approaches, because if you think about how complex a refinery is, it doesn't make sense to have a simple checklist on when you do your inspections or your audits. It might make more sense to tie that into, well, what are the areas that are most likely to have problems or challenges? Those are the areas we should focus on. So, I think we'll see more work in that area.
I think, quite frankly, we'll see work in things like carbon capture and underground storage. CCUS standards, I think, may present an opportunity for API to really support the industry as we move forward, and we all recognize what's likely to be a lower carbon, as they call it, future, because of the expectations of our stakeholders. I think we see opportunities there. And, of course, I've already mentioned the public engagement, really looking at the full lifecycle of that pipeline.
And we published a standard for that for hydraulic fracturing for the upstream group a number of years ago that really looks at the entire lifecycle of a field, and much like that, we're looking at that. What's that entire lifecycle of that pipeline, and how do you really get the public engaged so they support the activities that you're doing, and that they really feel like they're a part of the process? Awesome. Well, I think the way I'd like to wrap this up.
So, API is our sponsor for this first quarter of 2021. And David is the first guest we have to talk about API standards. We're going to be doing several other episodes about specific standards that are either new standards or soon to be published as revised standards. So, I'm really looking forward to those conversations.
And I'm just so blessed to have API sponsoring and participating, and I'm really glad that we're able to help get this word out. Well, Russell, I really appreciate the opportunity. I'm really excited to hear these other subject matter experts talking about these key standards that we're producing. And while we're on the subject of standards and standards making, I'd like to thank you for your service working on some of the standards committees, because I know that quite frankly, and this goes for you and all the other 7,000 volunteers, we recognize a lot of that work is done on nights and weekends and takes you away from your family and your leisure activities.
It's so vitally important. We just couldn't do this work without the SME. So, thank you very much for being an SME in the past, and hopefully we can bring you back at some point. Oh, I'm sure that'll happen there.
You guys keep working on standards I'm interested in, so I'm sure that'll happen. Great. Appreciate it. David, thanks for coming on.
It was great to talk to you, and we appreciate the API and all you guys do. Thank you so much. We appreciate the podcast. I hope you enjoyed this week's episode of the Pipe Liners Podcast and our conversation with David.
Just a reminder, before you go, you should register to win our customized Pipe Liners Podcast Yeti Tumblr. Simply visit pipelinerspodcast.com slash win and enter yourself in the drawing. If you'd like to support the podcast, best way to do that is to leave us a review on Apple Podcast. You can also leave us a review on whatever smart device podcast application you happen to use to listen.
You can find instructions at pipelinerspodcast.com. If you have ideas, questions, or topics you'd be interested in, please let me know on the contact us page at pipelinerspodcast.com or reach out to me on LinkedIn. Thanks for listening. I'll talk to you next week.