Under Pressure: Compressor Talk

From Heat Exchangers to Military Vehicles: Heinrich Bartels' Engineering Journey

• David Abshire

Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.

0:00 | 17:55

In this interview, Heinrich Bartels shares his diverse engineering career, insights on cost reduction, and the importance of collaboration across teams. Discover how his experiences in heat exchangers, military vehicles, and oil and gas have shaped his approach to engineering and cost management.

 key  topics

Engineering career evolution
Cost reduction strategies
Team collaboration and communication

SPEAKER_01

This is Under Pressure, Compressor Talk by Midwest Compressor. Strategies, systems, and stories from the compressor world. With your host, David Abshire. And now, on to the show.

SPEAKER_00

Good afternoon. This is David Abshire with the Under Pressure Podcast from Midwest Compressor. Today we have a guest, Heinrik Bartles. Heinrik, thank you so much for joining the show today. So we'll just jump right in. You've had a really unusual engineering career from heat exchangers to armored military vehicles to drilling equipment and now teaching cost reduction strategies. Looking back, how did that journey evolve the way it did?

SPEAKER_02

Well, I came here with my wife back in 1990 from South Africa. My first job was the heat exchanger job, and I was there for 10 years. But I did many very things there, so it was actually a good experience. I I learned to work in a small company. When you have a small company, you have a lot of different hats that you wear, everything from doing IT through, you know, running some of the CNC equipment out in the shop to doing engineering, both from a you know, analysis perspective and doing design calculations and really interacting with everyone. So that was a good experience. I left for uh BAE systems back then, and that was just more of that I had the background that I'd picked up from uh the heat exchanger shop and essentially evolved into develop developing vehicles. And I would have I've had an interest in developing vehicles for a long time. I mean, I've had an interest in Formula One since I was a kid. So going from heat exchangers to vehicles wasn't as big a step as some people may believe.

SPEAKER_00

You mentioned working on armored vehicle development for years before transitioning back into oil and gas. What's it like moving between those two worlds?

SPEAKER_02

You know, when you're looking at engineering, if you look at the basic level of engineering, isn't as much of a difference. If the application is different, and one of the things that you have to be more in consideration of when you're moving to a vehicle side is that there's a dynamic aspect. You have to understand the dynamics more than you would otherwise. Usually a lot of mechanical engineers are stuck in the statics world. But if you're working with vehicles, you really have to understand the dynamics piece of it as well.

SPEAKER_00

One thing that stood out was your work helping, you know, automate roughness systems on drilling rigs, replacing what used to be dangerous manual labor. How transformative was that shift for rig operations and safety?

SPEAKER_02

That shift happened back in the 90s when um a lot of people were getting their hands cut off and things like that, and and even getting killed on the rig. And that still happens even today, but there was a definite decline after they moved uh people out of the drill floor and started putting the automated equipment where people weren't directly on the drill floor as they were changing out uh drill parts, etc. And that's really reduced the number of injuries out in the uh in that world. And there's been a real focus on safety uh throughout the oil and gas industry, and and that was one of the aspects that came in was to reduce the amount of injuries and increase safety in in that kind of environment.

SPEAKER_00

Absolutely, yeah. And those and those types of automations that went on in that process, I can't even imagine you know how many fingers and toes it saved and and lives it saved, you know, just by taking out a lot of the manual stuff that was out there early on. You were in the industry during the downturn around 2014 when offshore activity really started collapsing. What was that period like from the inside in your perspective?

SPEAKER_02

I actually wasn't the offshore piece when it was occurring, and it was I'd just gotten to oil and gas from the vehicle side at that point, and it was kind of a uh a bit of a shocker seeing it it it starting collapsing. Already in 13, you could see the writing on the wall. And uh at that point I actually transitioned to uh forum uh energy technologies who were more on the land side. They had some offshore, but they weren't as affected by the downturn. Their downturn only occurred back at the end of 2014, and which is kind of when I went to them. But when it the downturn occurred there, there had so many very different activities that it wasn't as hard for them as some of the offshore guys. So it was in the end, it was a good transition to make. It was a bit of an eye-opener, but it also helped me transition into oil and gas since it wasn't as hectic.

SPEAKER_00

Yeah, absolutely. So you said a lot of your current work focuses on helping companies remove unnecessary costs from products and systems. What do most organizations misunderstand about cost reduction?

SPEAKER_02

I think that a lot of companies don't see cost reduction as a one-off type exercise. So you come across an issue where you are your margins are are low and you find at that point you need to start reducing, you think you need to start reducing cost, which is definitely apparent. But if you can get to the point where you are looking at cost at all times and looking at it more consistently, then you can keep your mar and your margins much more trimmer and keep higher margins if you can keep your your costs within check on a continuing basis. The other thing that people misunderstand is they think the engineers are responsible for cost or manufacturing engineers responsible for cost. And when you look at it truly, it's actually a lot of the organization that is responsible for costs. It's not just the engineering organization, it's the whole organization. And not only that, you need to be able to work together. If you don't work together, you don't see a lot of the the cost issues within the organization. It's only when you start talking to the other groups that you understand uh where the cost truly lies. Procurement has has a big piece of the cost, but if they don't understand when and where they can change things, they can actually make it worse rather than better. So that there is a the communication is key when it comes to uh keeping cost in check. I agree a hundred percent.

SPEAKER_00

One of the things that I really appreciated that you said was, you know, it's not just the engineer's job, it's everyone's job. And it takes everyone to work together to help reduce that cost. And I I've seen that over company over company over my career, where when you don't have the buyback from everybody to, you know, obviously work together to help, you know, focus towards cost reduction. And of course, too, it you know, increases profitability, which of course, too, lots of times creates more jobs, right? And creates more opportunity for the employees. And it's just a win-win for everybody across the board. I I definitely agree. Now you shared a great example where your team managed to roughly remove 20% of costs from a military control vehicle program. And surprisingly, part of the breakthrough came from the electrical system. What did that experience teach you?

SPEAKER_02

You don't always know where cost lies, especially if you don't understand all the elements of cost. You know, there's the cost is hidden. And if you haven't if you didn't actually design the equipment, which is the case for this particular piece of equipment, you don't understand where it's buried. And so you've got to dig in all the areas and give them all the chance to kind of per percolate. And as you give the engineers or the team a challenge, that's really the key, is I gave the team a challenge, said, this is what you can reduce it by. And how about it? What happened is I gave the electrical engineering, the team, the challenge. As it turned out, they beat that challenge. They just hit it out of the park. But there were other areas that we didn't quite meet it. So it was in some areas we didn't do as well, but the electrical side we really noticed that there were real inefficiencies in the electrical system where they had doubled up and tripled up in the electrical system. And what was key is trying to understand what the requirements were, what was actually needed, and then boiling it down to the essence, and but making sure that all the performance requirements were still in there, that nothing was lost when you did the cost reduction. So then you had a better performing system than the previous system at one-seventh of the cost, which is you know.

SPEAKER_00

Yeah, that's used. That's used as massive. Yes, absolutely. Now, one of the themes you kept coming back to was was requirements development, that projects succeed or fail based on how clearly teams define requirements up front. Why is this so critical?

SPEAKER_02

If you don't define what you're trying to achieve up front, you usually miss a few elements. So you don't fully understand what the customer wants, you don't fully understand what is trying to be achieved. And if you let the team loose in an environment where you don't have requirements, usually you get results that are not very useful. Or they will develop something that you will regret later on and you will actually you may have to trash. So you may have a development effort that you spent millions of dollars on and you come back and you say, Well, I can't use it because there was there's it's it's not something that you can actually promote. Whereas if you set up requirements, at least you have a fight-the chance. At least you you get people in from all different parts of the organization, just don't get engineering involved, get the leadership involved, get procurement, pull your sales team, also whole your customers, try to understand what needs to be in those requirements, what are people really looking for. And when you put those requirements and give it to a development team, at least they have a goalpost. They know where they've got ahead. And you also need to put cost into that piece as well. You can't just simply give them performance goals. So they need to be able to trade off performance against cost, performance against other objectives that you may have. And that's kind of what works well. And then when you do that, I found that the engineering teams really love it because they you can let them go. You can let them go for three, four months at a time. You still need to talk to them, you're gonna have reviews and get people involved in the reviews. But you don't have to be talking to them all the time because they know what they need to do.

SPEAKER_00

Absolutely. Yeah, I agree. Now you you described working with teams spread across multiple countries, Germans, Norwegians, Americans, all trying to agree on requirements before developing a new refneck system. How difficult was it to get everybody to work together?

SPEAKER_02

I didn't really appreciate what the challenge was when I started that. Everyone coming from very different perspectives, you know, you would think uh European, uh, you know Norwegians are Germans, got to be the same. Well, they're very, very different. And you know, and having an American culture come in from a totally different is a different piece as well. And the controlling interest was Norwegian at the time, and they had worked with the Germans for much longer than I had at that point. And they told me later on, they said, we don't know how you got the Germans to work on those, you change their thinking, and give us something that we really wanted all along. And it just came down to basically negotiating with them in the requirements set where they were writing part of writing the requirements, they were just told what to do. You had to listen to them, you had to kind of uh try to get their thoughts into as well. And once you gave them that, they were willing to move on other pieces that uh you wouldn't have thought they would move on. So that's kind of the core of it, is that I don't know, it was I I speak German, but that doesn't that's not the same. I mean, I'm from South Africa, so you know I'm culturally not German, but I uh I do speak German where Germans sometimes think I am German. And so it it is it's a bit of a problem.

SPEAKER_00

Right, right. No, I completely understand for sure. Now you said something really interesting that your big biggest success have usually come from involving more people and then not trying to solve the problems yourself or solve everything yourself. How did you learn from that lesson, bringing more people together to help solve everything instead of taking that responsibility on yourself?

SPEAKER_02

Well, I felt enough times about trying to do it myself, and after basically a number of hard knocks, found that I needed to release it. And as I moved into management, I knew that I couldn't do it myself anymore. And so at that point, I learned that if I could challenge people and let them be creative, you're gonna get a lot more out of people by letting them do things rather than trying to micromanage them. But the key thing is trying to challenge them. People where you give them goals, you'd be surprised as what they come up with. You can't do this yourself because you don't even have the bandwidth to be able to do it. The kind of project that we tackled, you need basically 80 to 100 people. If you do it, develop a whole new vehicle, you can't do that by yourself. You don't first of all have the technical knowledge to do it, and number two, you don't have the time to do it. But the creativity you get from getting teams together and making sure they talk to one another can be amazing. So I I've always been amazed letting people go and and really get things out of things, and that that's really been a key to a lot of things that I was successful with.

SPEAKER_00

Absolutely. I definitely agree. And sometimes just removing those boundaries of departments and roles and responsibilities, and just seating everybody in a room together and letting them, you know, just brainstorm and come up with ideas and speak freely, and then usually that creativity flows, and then you know, the communication, the team, and everything starts working together. So I definitely agree by bringing in the different faucets of people from different different roles and responsibilities, definitely helps in getting everybody to buy in to, you know, work together, which is extremely important. So if you had a magic wand to fix one thing inside large engineering organizations, you pointed to silos between engineering, manufacturing, and procurement. Why do those disconnects still create such major bottlenecks, in your opinion?

SPEAKER_02

I think there's not an appreciation for the business goals as a whole. Um, having been in business leadership as well, that the engineering organization, even the procurement organization, don't always fully understand what the business objectives are. And you have to be able to get people to understand that their thinking isn't necessarily gonna be better for the organization. You need to educate them and try to work through things. Uh, it's not something that happens overnight. As you kind of have these discussions and try to get people on board, they finally get it. It's just it just takes time to get people to understand that their thinking is not necessarily going to be beneficial to the business. There are other things to consider. Engineers can be very, very stubborn and very boundary driven where they don't like people climbing into their boundaries. I'm an engineer, so I understand it somewhat, but I've always had a little bit more of an open look at it. But uh, you know, it it's it's kind of tough when other people who don't have the education try to tell you how to do things better, but very often they have better ideas and you've got to take that into consideration.

SPEAKER_00

You know, that's one of the things I've learned over my career is, you know, the engineers that are successful, I've seen them, you know, obviously they're working hand in hand with everybody and have an open mind going into projects and different big construction type atmospheres and listening and and just having that open mind and being able to, you know, make changes if need to and not kind of die by the by the sword, is what I always like to say, or die on the sword. So essentially just being able to work well with people and communicate and you know, of course, too, be able to make sure that you're able to, you know, stay on track of what the mission is and the goal is or the project is and just move forward. I think that's one thing I've seen a lot with bigger engineering projects over my career is you know, they get stalled and get behind because not everybody's working together, right? And everybody starts in really aggressively and then they get together and you know they get indecisive and can't make decisions, and you know, the projects just kind of stall. And then of course, usually it costs time and money, you know, to get the projects moving again to kind of you know get them headed back in the right direction. So it's extremely important to be able to communicate good. And I I think that's one of the things that I I hear you say from your experience and your career is you know, working together as a team, being able to bring people together, be able to be a strong communicator, and then the rest is you know uphill from there. So I definitely, definitely appreciate your time today, Heinrik. Uh, thank you so much for jumping on the show. I definitely appreciate what you've done in the industry. Uh, of course, with your background, it's very, very skilled and very, very cool because I always like to hear everybody's different roles and with their backgrounds and definitely appreciate you jumping on. One of the things we do, Heinrik, for all of our guests, uh, just whenever you get a chance, if you can just email me your address, uh, we mail out a box. Uh, it's just like a gift box for saying, hey, thank you for coming on the show. Uh, it's generally got some Midwestern press or hats or something in them, or stickers or whatever, but the girls put them together in the office for us and they ship them out to all the guests that come on the show. So I definitely appreciate your time today. It's so nice to meet you and definitely it's super excited to see the show get published. Uh the the guys will edit it and put it out, and as soon as they do, they'll email you and let you know so you can share it on LinkedIn and everything. So I definitely appreciate your time today, Heinrich. Thank you so much. And you have a good rest of your afternoon, buddy. Thanks for the opportunity, David. Yes, thank you.

SPEAKER_01

This has been another great episode of Under Pressure. Compressor Talk by Midwest Compressor. With your host, David Abshire. Until next time, keep pumping.