This week’s Pipeliners Podcast episode features first-time guest Glenn Kelley of Muddy Boots discussing the opportunity to use a modern software platform to run field operations from your phone.
In this episode, you will learn more about the features and functionality of the Muddy Boots all-in-one field operations platform, how the software platform solves common headaches for pipeline operators supporting field operations, the difference between using an all-in-one platform versus multiple applications in the field, and more topics related to optimizing field operations through the use of a field operations software platform.
Pipeline Field Operations Show Notes, Links, and Insider Terms
- Glenn Kelley is the CEO of Muddy Boots Online. Connect with Glenn on LinkedIn.
- Muddy Boots provides field operations software for pipeline operators to manage critical areas such as measurement, maintenance, work orders, site diagrams, shift logs, and well lists.
- Access the referenced article on EQT founder Tony Rice discussing his vision to use oil and gas software that enables him to run the business from the palm of his hand.
- In Canada, government-mandated flow schematics are required to ensure measurement, accounting, and reporting compliance through the use of visual tool showing the current physical layout of the facility. Process flow diagrams (PFD) and piping and instrumentation diagrams (P&ID) are not considered measurement schematics.
- Process Flow Diagrams (PFDs) are generally used in chemical and process engineering to indicate the general flow of plant processes and equipment.
- Piping and Instrumentation Diagrams (P&ID) show piping, equipment, and instrumentation connections within process units.
- IIoT (Industrial Internet of Things) captures the use of industrialized devices suited for creating data, connectivity, data delivery, and consumption. This term encompasses sensors, edge computers, controllers, communication devices, PC’s, HMI’s, etc.
- SCADA (Supervisory Control and Data Acquisition) is a system of software and technology that allows pipeliners to control processes locally or at remote location. SCADA breaks down into two key functions: supervisory control and data acquisition. Included is managing the field, communication, and control room technology components that send and receive valuable data, allowing users to respond to the data.
- OPC (Open Platform Communications) is a data transfer standard for communicating device-level data between two locations, often between the field and the SCADA/HMI system. OPC allows many different programs to communicate with industrial hardware devices such as PLCs. The original system was dependent on MS Windows before shifting to open platform.
- Modbus is an older protocol that enables communication among many devices connected to the same network. The drawback is delays in the communication, oftentimes creating timestamp discrepancies.
- Schemaless Databases do not have a fixed data structure. This type of database makes no changes to the raw data and does not require conformance to a structured schema.
- Elasticsearch is a distributed search and analytics engine that was released in 2010. It provides a full-text search engine with an HTTP web interface and schema-free JSON documents.
- APIs (Application Programming Interface) enable separate applications to connect, communicate, and exchange data.
- GraphQL is an open-source data query and manipulation language for APIs.
- Flow meter calibration is the process of comparing the pre-set metering of a flow meter to a standard scale of measurement and adjusting the meter to conform to industry standards, such as API Chapter 4.
- Swabbing is the process of removing fluids from a production zone at an oil or gas well.
Pipeline Field Operations: Full Episode Transcript
Russel Treat: Welcome to the Pipeliners Podcast, episode 197, sponsored by ROSEN, the global leader in cutting-edge solutions across all areas of the integrity process chain, providing operators the data they need to make the best Integrity Management decisions. Find out more about ROSEN at ROSEN-Group.com.
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 that you’re taking the time. To show the appreciation, we give away a customized YETI tumbler to one listener every episode. This week, our winner is Steve Biagiotti at Dynamic Risk. Congratulations, Steve. Your YETI is on its way. To learn how you can win this signature prize, stick around till the end of this episode.
This week, Glenn Kelley, CEO of Muddy Boots, is joining us to talk about running pipeline field operations from your phone. Glenn, welcome to the Pipeliners Podcast.
Glenn Kelley: Thanks, Russel. Happy to be here.
Russel: We’ve been trying to get you on for a while. I’m glad we finally got you roped in.
Glenn: [laughs] Awesome.
Russel: Before we get going here, why don’t you tell us a little bit about yourself and about your background and how you landed in oil and gas and with Muddy Boots?
Glenn: For sure. I started out my career as a computer science guy. Went to university for that. Fortunate enough to land my first job with Amoco. I worked for Amoco for 17 years. Then I did a longish stint in consulting, all for the oil patch. Probably worked for 60 different companies on varying projects.
Then I put together a company called PEPR, which stood for Production Equipment Performance Reporting. It was all about natural gas compressors and how you optimize natural gas compressors and, if you’re a field guy, what are you going to do to tweak those to get different performance. After selling that company, I got Muddy Boots going. I’ve had a longish career focused on IT for pipelines and operations, yeah.
Russel: Cool. That’s an interesting story. You sold PEPR, which was a software company, and how long did you lounge about before you got the itch to do something new?
Glenn: Well, I didn’t lounge about at all. [laughter] There’s actually, to use one of my divorce lawyer’s terms, there was an overlap there. There was about two years, I guess, I’d had Muddy Boots in mind and got it rolling with another fellow where we were selling PEPR. At one point in time, I was consulting, doing PEPR, and doing Muddy Boots. Now, I’m just down to Muddy Boots, which is awesome.
Russel: [laughs] Yeah, I can relate to that story, Glenn. I can definitely relate to that story.
Glenn: You betcha.
Russel: How did you get the idea for Muddy Boots? It’s always interesting. I don’t get a lot of opportunities to talk to, for lack of a better way, a software entrepreneur. It’s always really interesting to me how people get their ideas and then how they take that idea and actually turn it into something that’s actually delivering value to somebody. How’d you get your idea?
Glenn: It’s the greatest feeling to have an idea and actualize that and make it happen. The inspiration for Muddy Boots came from decades of looking at what goes on in the field and the growth from one application for guys that were using pieces of paper to techs and operators that had 17 different tools they had to use every day.
I would get comments from people in the field, like, “Ah, please don’t bring me another tool to help me do my job. We don’t want any more software.” I had this great realization that we’d been building software from the head office out for all these years, and that’s what every discipline gave a tool to the field guys to use.
You needed to reverse that. You say, “What goes on in the field? How do I capture that data?” That data is then what’s needed by everybody. It came to light one day. I was hired by a largish software firm that wanted to bring a field data capture system into Canada. They said, “Should we do this?” and I said, “Well, this market’s saturated, right? Unless you make a step-change in the way that’s done, you’re going to fail.”
I said, “I don’t know what that step-change is,” but as I said that to that individual, I realized I did know what that step-change was. You need an all-in-one tool for operations designed for the field. That was the origin for Muddy Boots.
Russel: I find that fascinating. I have worked around field and field operations and field operations software off and on most of my career. I’ve seen various waves of technology come through, right?
Russel: I remember at one point, everybody was getting some kind of handheld device. They would set it in a cradle, and it would sync up, and then they would run around and they would do all of the things they would do on the clipboard, but they’d do them into a device. Then, they’d come back and plug it in a cradle, and it would download all its data and sync back up for the next day. We’ve come a long way from that.
I have certainly had the experience working around measurement where you go out with a measurement tech, and that guy’s got to have a dozen to two dozen different software applications on their laptop, and they’d all conflict a little bit one way or another, right?
Glenn: Absolutely. Yeah.
Russel: In terms of the drivers and communications and all that kind of stuff.
Glenn: Yeah, and there’re still guys out there running old DOS [Disk Operating System] machines today, just to get that stuff to work, right?
Glenn: I think the timing for us was fortuitous. We came into this with this mission to be all-in-one for the techs and the guys in the field. The computing technology was ripe. We put out software that, obviously, works on a desktop, tablet, a handheld, or a smartphone. People pick and choose what they want.
In the beginning, we got pushback from the older operators that said, “We don’t want to use technology.” I talk to them, and I tell some of these guys, “If you know how to text your girlfriend, you can use our software,” right?
Glenn: We made this really easy to use tool for the oil and gas guys, and 70-80 percent of them are doing all of this on their phones today. That’s what’s happening, and it works really, really well.
Russel: There was a very interesting article that was written by the founder of [EQT] [Tony Rice]. He was talking about how they transformed how they operated their business by getting everything on everybody’s phones, right?
Russel: That, when you say that, that’s like, “Well, of course. That makes so much sense,” and yet when you try to do it, [laughs] it’s a way different level of complexity, right?
Glenn: Yeah. Buy everybody phones and you’re done, right? No. [laughs]
Russel: Yeah. Yeah, right. The other thing I think that I want to visit with you about is you’re in Canada, and you started Muddy Boots to address a problem in Canada, I think more so than the U.S. Is that a fair comment?
Glenn: That’s a fair comment, but as part of the vision as we set out to build this all-in-one tool — nobody’s about to give us $20 million to do that — we had to pick a place to go into the market. What was going on in Canada at that time was a new provincial regulation that said you had to have flow schematics. All of the measurement people in Canada — all the pipeline operations in Canada — have government-mandated flow schematics.
Russel: Let me interrupt you, Glenn. Could you define for us what a flow schematic is and how it’s different than a P&ID diagram?
Glenn: Yeah, definitely. It’s a subset of a P&ID diagram, and it’s really tracking every product flow through every device that changes that product flow or stores that product, so in tanks, meters, schematics, pipelines, separators…
Russel: Separators, heaters, valves, all that kind of stuff.
Glenn: Yeah, all of that kind of stuff. We used that as an entry point to build the schematics tools, but for us, that schematics tool was the definition of your data, your master data. In our software, when you add a tank onto a schematic, you’ve added that asset into your inventory. The schematic and the asset data are one in this application.
Russel: This is actually one of the reasons I wanted to get you on and talk, because I can tell some real horror stories about drawings that I had or things I put together to do a project, and then going out to the field and finding out that what was actually in the field was something significantly different than what I had in my drawings.
I don’t know how many times I’ve done a project where a big part of the project was just driving out to all the sites and doing sketches of what was at the sites, and then sitting down in an office and popping up Visio and just doing a simple block diagram of “here’s what’s all there.”
Glenn: Yeah, and it happens time and time and time again, and you get things that have evolved and changed in the field. Nobody who does production accounting or other functions knows about that, right?
Glenn: It happens all the time. It’s a communication gap. We just had a review for a new customer last week. We fired up, and their production accountants were astounded to learn [laughs] where certain flows were going and that certain meters weren’t even being used. Just getting them together with that common diagram, it just works, and it works great.
Russel: I think the other things that I really like about y’all’s schematics is…What I typically do when I’m doing a SCADA project, we start with two drawings that we do. We do a topology diagram, which is basically what is all the communications gear, and how is it physically connected — how is it wired, and what are the radio paths? Then, we do a data flow diagram, which is a simple block diagram of all the software pieces and how the software’s connected. Is it OPC? Is it Modbus? Whatever.
Russel: The other thing we have to have is we have to have a good diagram of the process, because that’s what you’ve got to bring into the control center. When I look at the Muddy Boots schematics, what I see is good diagrams of the process, and they’re easy to understand, too. I can read a P&ID, but many people cannot, and it takes a little time to actually look at a P&ID and say, “Okay, what on this drawing actually matters to me?”
Glenn: Exactly, yeah.
Russel: Where just with a flow diagram, what matters to you becomes abundantly apparent right from the time you look at it.
Glenn: Right now, yeah, with our schematics, you can click on a point in the diagram and say, “Okay, tell me everything behind this compressor.” They go, “Okay, there’s 72 wells here that you’re going to impact if you take that compressor down,” and so on and so forth.
Russel: Again, I think that’s one of the things that in the real world, answering that question is never that straightforward.
Russel: At least, I know…Well, I won’t tell all my horror stories that I could tell about thinking I knew what was upstream and actually not knowing what was upstream.
Russel: Let me ask this question, because there are a ton of tools out there that automate the work around all the equipment in the field. They automate the asset list, and they automate the work orders and the MOCs and all the recurring maintenance tasks, and all that kind of stuff. There are a plethora. There is a bunch.
Glenn: There is a bunch, and competition is very real for us on a point-by-point basis. We are not the best maintenance system out there, and we’re not the best safety system out there, but we are that all-in-one tool. If you want one tool for your guys, you can come to us. The value there is you get all of the data from all of these functions in one place.
I mentioned schematics, and that was the literal tip of the iceberg. We then said, “What are all the activities that oil and gas people do?” and you take a look at inspections, valve tests, and “Am I managing the level of my propane tanks or my methanol tanks?”
Russel: And my mission reports and…
Glenn: Oh, mission…
Russel: …safety surveys…
Glenn: …and it’s huge, right?
Russel: …and on and on and on. I think the challenge, if you will, for the field operator, for the field technician is that…Well, I’ll put this together maybe a different way. There’s really two different things that are occurring, I think, in the organization. There’s analytical tasks that are being performed by engineers, where the ability to perform the analysis is the key thing they’re looking for in the tool.
Russel: The guys in the field — their primary job is keep it running and provide the data that other people need.
Glenn: That’s right.
Russel: That’s a great oversimplification, but I think that’s fundamentally the challenge.
Russel: Again, does that make sense? How does Muddy Boots address that reality?
Glenn: Lots of answers to that question. I’ll start with the engineers first, which is something I don’t normally do. They get the data they need, and so if I’m looking at measure tests, and I want to trend what’s going on over time, and look at that and change the frequency of those tests, I can.
If I’m an emissions guy, and I want to look at vent rates, fuel use, flair use, and all that kind of thing, I can look at that, trend that, and do some analysis there.
For the field guy that wants to keep things running, what does he do to keep things running? There’s a lot of talk these days about operations by exception. We’re moving the field person in to doing the highest priority things.
If there is a simple piece of maintenance to be done on a separator or another piece of equipment, that gets scheduled. If there’s regulatory inspections need to be done, that gets scheduled.
With the tool, the critical stuff gets scheduled for the operator, and so he knows, or can know, the most important things to work on every day. That’s what we’re doing for the operator.
Russel: Well, that, you just said a mouthful right there, Glenn.
Glenn: I did. I understand. [laughs]
Russel: Knowing the most important thing to work on every day, that is not an easy question to answer every day. It’s a very dynamic thing. There’s a lot of things that go into it.
Russel: To me, when I think about this and if I were trying to educate pipeline operators about the challenge around all this, where we’ve got to get to as an industry is we need to think differently about the field operators; the field technicians, and what they need in the way of tools versus what the engineers and the schedulers and the managers need in the way of tools. They’re fundamentally different, right?
Russel: The real benefit is if I can get a tool that’s easy to use, that keeps me connected with others, then I’m more likely to use that tool, which raises one of the other questions. How do you deal with the reality of folks working out of their trucks and in the back woods and in and out of cell connection or in and out of access to the company Intranet?
Glenn: So the mobility question. For us, every task that our operators do, they can do offline. They fire up their task list, their run sheet, whatever you want to call it, in the morning. They can be without service all day long.
Russel: [laughs] You’ll appreciate this. The listeners might need me to unpack this a little bit. The difference between a native app and a web app. My lead developer, a gentleman by the name of Scott Williams, he’s been on the podcast before. He and I have worked together for a long time. I remember we would get into this conversation about “Well, I want that to work on my phone.” Then that would spin out into “What do you mean by that?” What I meant by that is I want it to work on my phone without having my phone connected to anything.
Glenn: [laughs] Exactly.
Russel: What he heard was “I want it to work on my phone,” which are not the same thing, right?
Glenn: Not the same thing at all, no.
Russel: There’s a whole different level of challenge, if you will, to build something as a native app.
Glenn: Yeah. We set this up on guys’ phones. They’d do their run. The majority, especially in Canada and the remote places, they’re unconnected, and everything just works.
Quick story for you. I was out at a gas plant one time, and I was trying to egg on the operators to tell me what they didn’t like about the software. One of them basically told me, “You’ve got to quit asking the questions, because the software just works.” That was the best compliment I could ever get.
Russel: That’s about as good a compliment as you can get, particularly from a field guy, because they’re the ones that’ll really stress test something.
Let’s shift a little bit, because there’s another dynamic in the field that I think is important to understand. It’s very common in the field to be working with contractors. Like I may have an operator that is, I might be a pipeline operator, and I’m running around in my truck and doing the things I do. I, at any given time, might have two or three or four contractors doing things for me.
Glenn: Absolutely, yeah.
Russel: Some of that may be recurring maintenance. Some of that might be recurring measurement. Some of that might be special projects, but that need to collaborate with others is a big deal.
Glenn: It’s huge. It’s huge on the scheduling basis. When are people going to be there? What are they going to do? The information they provide, once they do that work, you need somewhere. There’s this plethora of PDFs and emails that goes back and forth today with all of these people.
We recognized from the start, it was part of our design to say, “Okay, if I’m looking at a single location, and all the people that are going to work here, some are our guys, and some are servicepeople. How do we connect the servicepeople?”
We built a feature — I call it Muddy Boots Connect — where you can take, as an operator, that pipeline and affiliate all your service companies. What does that do for you? Well, I’ll give you an example. They say they’ll do meter calibrations for us, but they’re only doing them in the south area and not the north area. For an affiliate, you can say here is the activities they’re allowed to do, and where they’re allowed to do them. They literally can use Muddy Boots to record those activities, and we get great success with that.
We’ve got oil companies out there that have 9, 10, 11 service providers doing calibration, swabbing, or other kinds of inspections, and then all of that data is just there in your system. I keep using this word “activities.” We have now 500 plus different activities the field people or service people can do.
Every once in a while, with service people they say, “We want to use our own system.” We say, “Okay, but you’ve got to schedule with your client, so when you use your own system, and you’ve got your own PDF, you just fire up the Muddy Boots activity. Okay, that job’s done. Connect your PDF as attachment and boom, it’s all there.” We find ways to be accommodating for all the service people.
Russel: I was just going to say, Glenn, I think the value proposition of that for both the operator and the service company is they both have visibility into the work that’s being performed.
Glenn: The work, yeah, particularly the schedule, because the schedules are always changing.
Russel: Yeah, exactly. They’re always changing, and always need to know, “Okay, what do I need to do to get somebody to this point to do this thing in this time frame?”
Glenn: That’s right.
Russel: As an operator, having visibility across all my contractors to know, “Oh, well, I can move this stuff around,” and just do that, there’s huge, huge value in that. Likewise, knowing as a contractor that, “Okay, here’s the work that the company has planned for me to do,” and have a visibility out, that’s likewise a big deal.
Glenn: It’s perfect, yeah.
Russel: What other kind of technical capabilities matter in a tool like this? We’ve talked about mobility and the ability to work offline, but what other kind of technical capabilities matter?
Glenn: Russel, there’s a few things here. If you think about how dynamic we are and the breadth of things we need to do — and we’ll always need to do more things — we architected this with some pretty cool technology. Just to enumerate a couple, right? Part of our database profile, part of the back-end is a schemaless database that allows us to add new information on the go, literally.
Russel: Let’s unpack it and define “schemaless” for the listeners. A database schema is a very structured definition of how I’m going to store the data, and a schemaless is, well, the data can kind of be in any shape or form it wants to be.
Glenn: Any shape or form it wants to be, and it can morph. It can add, subtract. This customer needs these things, that customer does not want those things. We tweak things for people’s needs quite handily, like on the go, over the phone.
Russel: That, being a software guy, blows my mind. That just blows up my whole mind, because I don’t know how you do that.
Glenn: It wasn’t easy, but I’ll just say we’ve got some great architects behind the product. One of our original guys built up another piece of software that ended up having 2,000 clients, and he learned a lot of tricks.
Russel, just let me give you another one, because we make great use of this tool called Elasticsearch. Elasticsearch, I think of as an index on everything. Literally, because we’re dynamic, because we do so many things, if you want to go in and find equipment failures or search on any term, you can. Elasticsearch is that same tool that Google and Facebook use for searching. It’s really, really cool, and it’s got some aggregation features and so on and so forth. Then I think the other bit of technology is the way we do APIs, because we use Elasticsearch to find data. We use GraphQL to normalize that and deliver.
We get connections to a lot of other applications. We import analysis from the labs, and we deliver work orders. We receive work orders and MOCs from control room software and all that kind of thing. Searching database APIs, I guess, is where we focus some pretty cool technology.
Russel: Yeah, again, Elasticsearch, that’s one of those things I think’s really cool, and I don’t understand how it works. It’s like I need some education there. I think everybody understands how quickly Google pulls things back, and it knows that, if you type these three letters, you’re like to type these next six. [laughs]
However that Elasticsearch is working, it’s very, very strange. The idea of working with data in a way that the data’s very quick, and it comes up, but it’s not well-structured, it’s just counterintuitive, man. To me, it’s just counterintuitive, but I’m an old-school software guy. I learned to do it a different way.
Glenn: Yeah, it’s not what we’ve been doing.
Russel: Are you going to tell me any of your secrets? What’s the deal, man?
Glenn: I think the idea’s no more than listening to smart people and setting out a vision, right? Maybe setting out a vision and listening to smart people.
Russel: Yeah, I want to know how to do schemaless data, and I want to know how to do Elasticsearch.
Glenn: Yeah, you bet.
Russel: I think that’s really, really…I’m being a flippant here, but I think it’s really critical when you start thinking about building a cloud-based, field-centric, smart device-centric solution. Those two things are really critical.
Russel: When I’m in the field on my phone, and I need to search for something, I don’t want to have to go through 15 menus, setting up filters and everything else, to go find something.
Glenn: They won’t do it, no.
Russel: Yeah, exactly, and also, for the younger generation, their expectation of how that stuff should work is just different.
Glenn: Yeah, off the charts.
Russel: What do you think the future is? What do you think are the things that are going to be happening with technology in the field for field operations?
Glenn: I see a couple big trends here, and one is operations by exceptions, which goes under a few different names. Basically, the high grading of “What are my field people going to do? How can I reduce cost? How can I reduce windshield time and all of that by, more intelligently, scheduling, and prioritizing their tasks?”
We get asked about that a lot. We continue to add functions that help with that. For example, we just put in a permitting function, so as a maintenance foreman, you can have somebody show up onsite. You don’t have to be there. You can sign the safe work permit, get approval online, go off, and have that person do their job without wasting your travel time.
Emissions is a second trend that we all have to pay a huge amount of attention to. I got a spreadsheet from a client this morning that said, “We need to do this, and we need to do it right away.” It’s all about tracking vent gas and tracking pneumatic devices and calculating methane use, all that. That’s huge. We have some tools there now, and we’re going to increase that portfolio.
Maybe the third theme I’ll mention is — I hate using this word, because it’s so generic, but the Internet of Things. People that build new devices, whatever they’re for, like imaging devices that need a home for that data. You need a place for that data to come to. Yes, we handle what operators do. Yes, we handle what service companies do, and now, we’re getting many requests and doing better in terms of bringing data in from the device manufacturers out there. Not some of the future stuff, for sure.
Russel: Yeah, no doubt, no doubt. I certainly think there’s going to be a lot more automation happening in the field. There’s going to be a lot more data getting collected. I’ve certainly looked at this in-depth as it relates to SCADA, operations, automation, and all that.
When you start talking about mobile devices and their ability to interface with these devices in the field that are intelligent, can collect large datasets, and give you the ability to visualize those large datasets, that creates some real opportunity, again, just to get to another level of efficiency and effectiveness.
Glenn: Absolutely, yep.
Russel: I don’t think, for those of us that play in the software, we’re going to run out of things to do.
Glenn: [laughs] Hasn’t happened yet, no.
Russel: [laughs] No, it hasn’t, it hasn’t. Look, let me ask you this as a wind-up question. What would you want pipeline operators to take away from this conversation?
Glenn: I guess a few things. If you’re using paper, why? If you are struggling to schedule what your technical people are doing in the field every day, there are better ways. If you need to be more dynamic about how the calibration is done or checking a compressor or what have you, there are better ways and lots of opportunities to do it better, but you have to think a bit holistically.
Russel: Right. Yeah. It’s basically one tool to handle it all.
Glenn: One tool to handle it all, yeah.
Russel: I think that, if you can take and transform the role of the person running around in the pickup truck from, “I’ve got a laptop, and I’ve got to open up my laptop, fire up my laptop, and get to the right application to do this thing I’m here to do,” to, “I pick up my phone, and it’s already open to what I need it to be open to, because it knows where I’m at, and it knows what’s on my schedule,” that by itself, that’s the real takeaway.
That’s what you want to do, right?
Glenn: That’s right.
Russel: I don’t want to have to open up my laptop and figure out which app, open up the app, and open up the right record in the app in order to start putting data in, right?
Glenn: That’s right.
Russel: I can’t tell you how many times I’ve done that in my pickup truck and that took 15 minutes just to do that.
Glenn: I know, yeah.
Russel: Then you get back to the office and you’ve got to sync every one of those applications, versus I roll up in my pickup truck and I look down at my phone. It’s already got the right thing open, because it knows my schedule. It knows where I’m at, so it knows what to open.
Glenn: Syncing for us means at some point in time, you drive back into cell service and the information just transfers, right?
Glenn: It’s seamless operation.
Russel: Yeah. Well, listen. This has been fun. I probably need to take you out on a hunting trip and get some whiskey. Maybe I can learn a little bit about schemaless data and Elasticsearch.
Glenn: That sounds like a plan, Russel. Yeah. We’ll figure out how to get that on the calendar.
Russel: You bet. All right, take care.
I hope you enjoyed this week’s episode of the Pipeliners Podcast and our conversation with Glenn. Just a reminder before you go, you should register to win our customized Pipeliners Podcast YETI tumbler. Simply visit pipelinepodcastnetwork.com/win to enter yourself in the drawing.
If you’d like to support the podcast, please leave us a review on Apple Podcast, Google Play, or on your smart device podcast app. You could find instructions at pipelinepodcastnetwork.com.
Russel: If you have ideas, questions, or topics you’d be interested in, 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.
Transcription by CastingWords