Episode 4: From Resistance to Readiness: Embracing Change in PLM with Patrick Hillberg

In this episode of the Share PLM Podcast, we are joined by Patrick Hillberg, an adjunct professor at Oakland University, where he teaches a graduate course in engineering management (called "Product Lifecycle Management") and is an Industry Advisor to the Department of Industrial and Systems Engineering. Patrick has decades of industry experience in designing, developing and leading teams in Product Lifecycle Management (PLM), Digital Twins, Digital Manufacturing, Process Planning, Robotics, and Machine Vision applications in Aerospace, Shipbuilding, Automotive, Construction, Packaging, and other industries. 

Join us as we dive deep into these topics:

⚉ Product Lifecycle Management (PLM) and Sustainability
⚉ Engineering ethics and catastrophic product failures
⚉ The role of culture in engineering and business decisions
⚉ Engineering Change Management: People vs. Process
⚉ What does a solution architect do?
⚉ Solution Architect vs. Project Manager
⚉ Agile approaches and communication in engineering projects
⚉ Are meetings a waste of time?
⚉ The rise of software-defined vehicles and new safety challenges
⚉ Traditional waterfall project management vs. agile methodology
⚉ Traditional waterfall approach vs. agile systems thinking in academia
⚉ Balancing finance, learning, and uncertainty
⚉ PLM approaches in the US vs. Germany
⚉ The role of human resources in PLM implementation


CONNECT WITH PATRICK:
Linkedin: https://www.linkedin.com/in/patrickhillberg/ 

CONNECT WITH SHARE PLM:
Website: https://shareplm.com/ 


Join us every month to listen to fascinating interviews, where we cover a wide array of topics, from actionable tips, to personal experiences, to strategies that you can implement into your PLM strategy.

If you have an interesting story to share and want to join the conversation, contact us and let's chat. We can't wait to hear from you!

Transcript

[00:00:11] BEATRIZ GONZALEZ:
Hello everyone and welcome to the Share PLM podcast. I am Beatrice Gonzalez, CEO of Share PLM and today joining me as always is my lovely co-host Jos Voskuil. So hello Jos, how are you doing? And who is with us today?

[00:00:27] JOS VOSKUIL:
Hola.

[00:00:27] BEATRIZ GONZALEZ:
Hola

[00:00:29] JOS VOSKUIL:
Well, today we are joined by Patrick Hillberg. And Patrick is an adjunct professor at the Oakland University. And we know each other already a long time through meetings. First of all, on LinkedIn and later also with the PLM Global Green Alliance. Where also where Patrick has participated in many discussions. But first of all, I'm curious how would you introduce yourself, Patrick? And welcome, of course, to the podcast.

[00:00:53] PATRICK HILLBERG:
Oh thank you. And yes, yes, you are looking particularly lovely today. So I just want to highlight that. So, I would introduce myself now. I definitely introduce myself as an adjunct professor. I usually use the word professor at Oakland University. I teach a course called Product Lifecycle Management. Although to be honest, a better name for that course would be Managing Product Life cycles for a Sustainable Future. Because I'm very into sustainability, it's very much a systems thinking course, etc. and the students who take my class I live in in the Detroit area, the students who take my class are mostly in the auto industry, so we spend a lot of time talking about the the larger system around the product lifecycle of automobiles, as I throw a lot of words all in there. So previousl I had two roles at Siemens. I was the US lead for academic and workforce development, and prior to that I was the lead architect. So architecting systems for some of our clients generally in kind of the small and medium business realm. In prior to that, I was at Dassault as a data architect, and prior to that I worked in the manufacturing industry doing robots and software and those sorts of things. So it's a manufacturing background that then moved on into the PLM space and now academics.

[00:02:12] JOS VOSKUIL:
So great introduction, Patrick. And great also to hear that you want to extend the definition of to PLM and sustainability. And I was curious, how would you translate this in your teaching?

[00:02:24] PATRICK HILLBERG:
I Started teaching the classes very much a PLM technology class. And then a few things happened. One, I was working with a client on their change management practices, and during that engagement with the client, General Motors had an issue with their ignition switch and GM had problems in how they managed change. And our client wanted to continue to do the same thing that GM had done. And I realized at that point that the culture at the client was not ready to learn from the very difficult problems that the GM had had and with the ignition switch, there were a number of people who it just was a big, big problem.

[00:03:10] JOS VOSKUIL: 
Just a question on the GM ignition switch. Is this the famous one where everyone talks about when discussing configuration management and quality?

[00:03:18] PATRICK HILLBERG:
Yes. Right.

[00:03:19] JOS VOSKUIL:
Yeah. Yeah.

[00:03:20] PATRICK HILLBERG:
I'll go. I'll go through a bit of it. So the ignition switch was designed in the late 90s, early 2000. It was released out into the field the tension on the spring was not strong enough. And when a car would go off the road and would hit a few bumps, the ignition switch would fall out of the run position. And when it fell out of the run position, the airbag software said, oh, if you're not in run, you must not need us to be airbags anymore. And the airbag would disable itself just a second before the car hit a tree.

And so 124 people died because of this. There were many, many more injuries. I don't have the number off the top of my head. And one of the things that came out in this was that a design release engineer, had modified how the switch was built without following through on form, fit, and function. In other words, he changed the function of the switch by changing the tension, but he did not update the part number. And because he did not update the part number once GM recognized oh, we really do have a problem, they were not able to to determine which cars had the the wrong ignition switch in it. So there was about two years of production where the ignition switch was weak. There was another eight years of production where the ignition switch spring tension was fine, but there was no way to figure out which was which. And that's a change management issue. So when you're dealing with configuration management, when he changed the function of the switch by changing the tension, that changes the function, but he did not update the part number to let anybody know that. And then I can go on.

[00:05:05] JOS VOSKUIL:
Okay. But, uh, yeah, I think it's an interesting story, and I think it's a must know story for engineers. So I'm also curious about how do you teach those engineers those practices? I mean, we can we can always say what went wrong, but it went wrong because the methodology was not there or not clear or.

[00:05:24] PATRICK HILLBERG:
Actually, no, that's a terrific question because I learned a ton from my students in the process of teaching the ignition switch. So GM had paid for an external legal report, and I was teaching the legal report as it was written and said, look at all these problems that occurred because change management was not handled well. And then my students who work in the auto industry, in fact, some of them have the same position as the person who behaved unethically. They started talking to me about the larger issues around the product development process. And one of the issues that, in fact, I went back and reread the report in detail based on the questions that my students were asking, and I ended up writing my own paper on it. So to answer your question is I wrote my own article, which I teach my students. But the key point of the article is there was a software team who made a decision to not deploy the airbag, and they did based on the position of the ignition switch. And the software team never told the ignition switch person that they were making that decision. So they had inserted the ignition switch into the safety loop without telling the person responsible for the ignition switch that he was working in the safety loop.

[00:06:41] JOS VOSKUIL:
Okay. And now back to Patrick.

[00:06:44] PATRICK HILLBERG:
Sure.

[00:06:44] JOS VOSKUIL:
I think we analyzed the GM a lot. Yeah.

[00:06:48] PATRICK HILLBERG:
I was in the process of teaching the switch during the semester in 2019, and the second Boeing 737 Max went down in the midst of teaching it. And suddenly everybody wants to talk about the Max. So once again, I went and did some investigation. I wrote my own article on it, but you can see similar issues. And this eventually, I'm getting back to your question. I teach that culture is an immensely important part of the product life cycle, and it's a part of the product life cycle that the very technical people don't tend to pay attention to.

So there were cultural walls inside General Motors such that the software people didn't think to tell the ignition switch person that they were including him in the safety cycle. And there were cultural issues at Boeing, and I have to go through some depth in order to get real into it. But there was a test pilot who didn't really want to make use of this autonomy, but he decided, okay, in very rare circumstances, he can do it. And then there's a different set of test pilots who said, oh no, no, let's use it more often in. The engineers never questioned him. And then there was a third test pilot who said, oh, wait, there's weird things going on here. We should deal with this. But if we're going to deal with this, then we're going to delay certification and therefore delay the launch.

[00:08:02] PATRICK HILLBERG:
So there's all these different cultural issues that show up in these these catastrophic product failures. And this is what I want to take my students through, is I want them to walk through what happened at General Motors and what happened at Boeing. And we get a little bit into autonomous vehicles and what might be happening there. And I want my students who are engineering managers in the automotive industry, I want them to walk through some of these difficult ethical dilemmas in the safety of my classroom. We can talk about anything in my class, right, before they go out into the world and have to start making these decisions on their own. So they're going to be managing teams where they have to deal with these, these questions of how, you know, there's this very small chance that something very bad will happen. How do I manage this issue in my team? So in any event, when we get to teaching I bring these catastrophic product failures in so that my engineering managers get a sense of what they're seeing when they actually see it.

[00:09:04] BEATRIZ GONZALEZ:
It is a very interesting point that what we always call engineering change management is also very related to the people change management organization and change management. So this is also, from your point of view, when you apply in the systems methods to control the engineering change, engineering changes so everyone is aware notified. Are you also considering from your experience also the cultural perspective how the people like to be notified or this kind of things?

[00:09:36] PATRICK HILLBERG:
Yes, most definitely. And I know I was having this conversation recently with a friend of yours, Oleg Solovetsky, and we were talking about how do you communicate, how do you start going through impact analysis? How do you really recognize all the impacts that your change is about to have as you're going through the change process and you definitely get into things as a matter of fact. So really, what I was doing, at both Siemens and Dassault was helping redesign the business process around change management. So and now you're getting into swim lanes and all those sorts of things. And how do you inform people of of changes that are going on. So what you really run into is a cultural resistance to change, and in terms of how you manage. The culture resists change in how you manage engineering change. So in any event, it's a difficult problem.

[00:10:28] BEATRIZ GONZALEZ:
Yes. I think it also depends a lot on the industry, how they control the the engineering changes, because there are industries like the ones you were mentioning, that they are more conservative. They need to control more the changes and other ones that are more flexible because it's not impacting the safety of the of the people at the end. So yeah,

[00:10:47] PATRICK HILLBERG:
Yes. And I think there is something there about as software becomes, we're talking about software defined vehicles and we're seeing software companies get into the the automotive industry. And my background is software development, when I was writing software for robots, the robots were behind a fence and there was no way for the robot to move unless the fence was closed and no one was inside the the area, right.

I mean, I there was a physical safety layer because sometimes my software was wrong. Sometimes I did things. I put the biggest crease into the side of a Volkswagen at one point, because I made a mistake in my math when we started getting into autonomy out in the real life world. Now a software bug can cause real problems. I mean, now a software bug can injure or kill people. We have to pay a lot of attention to that and more attention to that than I think that we have. So there's a lot of what I talk about in my class.

[00:11:37] JOS VOSKUIL:
Patrick, you started in your introduction also about being a solution architect.

[00:11:43] PATRICK HILLBERG:
Yes.

[00:11:44] JOS VOSKUIL:
And can you describe a little bit for the audience? What is the typical value of a solution architect. Is he another layer of bureaucracy or is he bringing value to the business?

[00:11:54] PATRICK HILLBERG:
Yes on both accounts. Yeah the solution architect phrase covers a wide range of things. In fact, my boss at Siemens said that when his boss asked for a solution architect, there was a spectrum of solution architects and I defined one end of the spectrum, and there was somebody else who defined completely the other end. So, and you just knew with me I had a very technical background, but I realized that culture was the big issue and I became the cultural solution architect. So when culture was your issue then you brought me in. So certainly solution architects have a lot of value.

[00:12:25] PATRICK HILLBERG:
My particular value, I felt, was helping the team function well. So I'm very concerned about dysfunction and and how do we function well. I'm very interested in collective learning. So when I was architecting projects, I would use an agile approach to architect the project, and I would really focus on getting the team to learn. So how can the team collectively learn from each other?

And I'll tell you, I bring that very much into my, my teaching as well. My students post their homework to a global forum that everybody in the class can see, and then they respond back on what others did. When I was architecting projects using an agile approach. It was very much the same sort of thing. We don't necessarily know at the beginning where we're going to end. We're going to learn as we go along. And then there's a regular cadence by which everybody shared information.

[00:13:19] JOS VOSKUIL:
Yeah. When I work with solution architects, there were often the glue. I mean, you had in the team a lot of specialists that the CAD guy who knew everything, the PDM guy who knew everything. And then to break it to a coherent story, for that, we needed the solution. Architect more or less bring us the solution, dear architect. That. Yeah.

[00:14:46] BEATRIZ GONZALEZ:
Is it not the project manager who is making the glue in the project? The project manager and the solution architect gives the technical solution. Right.

[00:14:55] JOS VOSKUIL:
Yeah.

[00:14:55] BEATRIZ GONZALEZ:
Understanding the business and the technology.

[00:14:58] JOS VOSKUIL:
There is always the discussion, I think. Should a project manager be content driven or governance driven? I mean,

[00:15:05] BEATRIZ GONZALEZ:
Yeah.

[00:15:05] JOS VOSKUIL:
I've seen these two…

[00:15:06] BEATRIZ GONZALEZ:
…or change

[00:15:07] JOS VOSKUIL:
…types of. Yeah, yeah

[00:15:08] BEATRIZ GONZALEZ:
Or people change driven.

[00:15:09] JOS VOSKUIL:
Yeah, yeah. I mean it's what they are…

[00:15:11] BEATRIZ GONZALEZ:
Like I think this is what Patrick was saying, right? This cultural solution architect, right?

[00:15:18] PATRICK HILLBERG:
Yeah. And and I had my own approach on it. I had project managers on the jobs where where I was leading the project managers in that scenario anyway, were very much into the administration of the team. That team had a dozen or so people on it and we were supporting another 40 from the customer. So there was a lot of administrative work, and I was so happy to not have to be doing that administrative work. So,

[00:15:39] JOS VOSKUIL:
Mhm. Exactly. Yeah.

[00:15:41] PATRICK HILLBERG:
And I realized that I did not nearly know as much as the people on my teams. I mean, I led this team of, like I said, a dozen or so people on it, and they all knew more than I did. My key factor actually, was getting them to communicate to each other so that a specialist in one area who was just an excellent person in that area, he might be having an impact on a specialist in a different area. And my role at this point was then to get the guys talking on a regular basis so that they realize that they were they were impacting each other.

[00:16:17] JOS VOSKUIL:
And how did you do that? By organizing ad hoc meetings or planned meetings or…

[00:16:23] PATRICK HILLBERG:
Yeah, we kicked off scrum right from the beginning and the most major project where I did this on actually scrum was brand new. So we had to teach people the idea of scrum. Early on we started with the 15 minute stand up meetings that eventually evolved into my team would meet Mondays and Wednesdays and actually, we had a get a little detailed here, but we had a SharePoint site and each person could bring in three bullets to talk about, and each of those bullets could only have three bullet sub bullets underneath it. And we would go around the table and everybody would talk about their bullets. Right?

So part of the deal there was you got to compress your problem down to the point that you can describe it in three bullets. Then so my team of a dozen supported a client team of another 40 to 50. And we had a Friday morning meeting. That I mean, 50 people would show up for it. It was a voluntary meeting and 50 people, most of whom are middle managers, would come to that meeting because they felt that it was important to be involved. And that meeting really drove progress.

Different clients would get up and speak in that meeting about what they had done over the course of the week. And in the course of that, they would all learn from each other. And the example I give on this is that, Alice and Betty would stand up to talk about something, and then Charlie would realize that Charlie was interested in what Alan and Betty was saying. And me as the lead architect, I had no idea that Charlie was interested in this, but because Charlie was in the meeting and listened to Al and Betty. Then Charlie said. Oh, wait a second. I'm interested in this too.

[00:17:54] JOS VOSKUIL:
Okay. You talk a lot about the meetings, Patrick. And I was just thinking at the old paradigm of meetings back to back. You move from one room to the other, and you are too busy from running, from meeting to meeting. Has anything changed in this agile approach? Also, in the modern way of communicating, like we do now through the internet, instead of running from room to room? Do you see changes there?

[00:18:15] PATRICK HILLBERG:
Yeah. And it's been 7 or 8 years since since I truly ran a project like that. But, I think if the meetings are valuable, then they should take as much time as there is value. For the 50 people who would show up in that meeting, they would probably only be interested for maybe 20 minutes or so, but they didn't know which 20 minutes they were going to be interested in. So they would bring their PCs in and they would work on their email and they'd do other things, and then half listen to the conversation…

[00:18:37] JOS VOSKUIL:
Yeah.

[00:18:38] PATRICK HILLBERG:
…that was that was going on around them. But we I mean, quite frankly, we were massively changing the organization. We were not simply implementing a new piece of technology to do what they were already doing. We were implementing a new piece of technology to change what they were doing. So they needed to be involved.

Yeah, the meetings take time. But the meetings, I think there were voluntary meetings and people still showed up. They didn't have to show up, and yet they still showed up. So they knew that they wanted to be involved in this.

I bumped into somebody. I started that project ten years ago, and it was just me and one other guy, and I bumped into somebody about a year ago who was a client at that company who I had not met when I was there. And he told me, yeah, we're still using that same stuff. So the stuff that we had. So that my point is that, yeah, there was a lot of meetings. There was a lot of there was at least three hours a week that you were going to spend in a meeting, but we were making the decisions. At ten years later, we're still having an impact on the company. So I think it was just good. It was good cost benefit analysis.

[00:19:40] JOS VOSKUIL:
Okay. And I mean, if we look back to the old ways of working, then we, you talked about project management. Often we had this big waterfall project that was the typical PLM project. In the beginning, there was a system coming and we had to implement it and we plan it. And by the way, we have also people to to implement. But that was the last point. Now with agile the approach is different. Where did you see this happening?

[00:20:08] PATRICK HILLBERG:
You mean the switch from

[00:20:09] JOS VOSKUIL:
Yeah. From

[00:20:10] PATRICK HILLBERG:
From

[00:20:10] JOS VOSKUIL:
Waterfall to agile.

[00:20:12] PATRICK HILLBERG:
Waterfall to agile? Yeah, eventually. Waterfall is we figured the whole thing out front, and then we slowly detail it out and then each person works on the detail, and then we bring the whole thing back together again. And hopefully it all works. And what you, what you get to at the end is you realize that it doesn't work and then everybody panics. Right?

Agile as I advocate and not everybody advocates this. I advocate agile as a collective learning approach. So our real goal is to learn as we go along. And as we learn, we change our minds. And that's where the agility part comes in. Is, is like, oh, wait a second. This thing that we thought we wanted at the beginning is not the thing that we actually want, and we'll go off and do something else. There's something I think my sense in reading LinkedIn and some oh, even Harvard Business Review is starting to talk about this Now people are implementing Scrum and Agile without really giving up on the waterfall approach. So they're taking a waterfall approach and trying to break it down into sprints without really adopting the realization that maybe we're wrong at the beginning, and maybe we need to change our mind as we go through. So,

[00:21:24] JOS VOSKUIL:
Right?

[00:21:24] PATRICK HILLBERG:
So I think that's the big change from waterfall to to agile is you have to accept that you don't know everything at the beginning and you're going to change your mind as you go along.

[00:21:35] BEATRIZ GONZALEZ:
And what is the university's approach? So they are training more the students in waterfall or it's only AI.

[00:21:43] PATRICK HILLBERG:
Yeah.

[00:21:43] BEATRIZ GONZALEZ:
What are the approach you are that that you are on that area?

[00:21:47] PATRICK HILLBERG:
Yeah. So you asked so as I'm about to get fired. So the Universities actually take a very, each professor works in their own way and I don't think it's only my university that's like this. Right? There's a project management class that teaches very much a waterfall approach. I teach a systems thinking class, which is very much an agile approach.

[00:22:12] BEATRIZ GONZALEZ:
Mm.

[00:22:13] PATRICK HILLBERG:
What's interesting, actually, is I'm getting a lot of now I'm starting to get students who already have their certified Scrum Masters. When I first started teaching agile ten years ago, my students would just look at me with a blank look on their face. Now I have actual certified Scrum masters in the room.

[00:22:28] JOS VOSKUIL:
And I was thinking also, Patrick, in the past in particular, it was the top management that wanted a waterfall. They want to see the results in one year. We have spent the money now everything should be up and running. Where actually in the field, the people that needed to implement it, they had no clue what to do. As you we said, they had to learn. What can the software do? What? How does it work for us? And that's where always the big tension is. I've seen some very big projects fail because on the top level, there was this 1 or 2 year plan to implement with milestones and reality on the floor. Could never achieve it unless you fooled your boss and you say we are perfectly happy.

[00:23:08] PATRICK HILLBERG:
Yeah, there's there's this fundamental tension and tension can be good, but there's this fundamental tension where on the financial side we want certainty. And on the technical side, we're learning. And and the fact that we're learning implies that we don't have certainty. If we had certainty, we don't need to learn anything new. So how do you make this balance between finance and learning with this piece of uncertainty in the middle?

Now my comment and I've got some slides and lectures on this is that when the finance side wants certainty, I mean the investors want certainty. So you go to each of the different layers on the waterfall and say, give me a certain amount of time that it will take you to do this. Well, when we're asked if you ask me for Patrick, how long will it take you to get this job done? And if I know that, it's like, well, it might take me a week, it might take me three weeks, I'm going to tell you four weeks because…

[00:24:07] BEATRIZ GONZALEZ:
Mm.

[00:24:08] PATRICK HILLBERG:
…I won't get fired if I'm done in less than four weeks. But I might get fired if it takes me…

[00:24:12] BEATRIZ GONZALEZ:
Mm.

[00:24:12] PATRICK HILLBERG:
…more than one.

[00:24:14] JOS VOSKUIL:
Okay,

[00:24:14] BEATRIZ GONZALEZ:
Yeah.

[00:24:15] JOS VOSKUIL:
As I understand it, Patrick, you have worked also a lot in Germany. So I was curious, do you see a difference in the PLM approach in the US and in Germany? I mean, I can give my prejudgments, but I'll let you have the floor.

[00:24:30] PATRICK HILLBERG:
I can only speak for the one multinational where I did that with. So I don't want to cast all of the US and all of Germany under a certain thing.

What was interesting to me in this was that in this particular company, the American side was very interested in margins. So anything that they could do to to reduce cost, they would do it.

[00:24:52] JOS VOSKUIL:
Mhm.

[00:24:53] PATRICK HILLBERG:
One of my colleagues said what I thought was a pretty funny joke. He said, I'd hate to be in a room with four directors when someone sees a nickel on the floor. The idea is that they would all jump on that nickel, and they'd be fighting each other over a nickel.

[00:25:05] JOS VOSKUIL:
So business focus huh.

[00:25:06] PATRICK HILLBERG:
Yeah. Right.

[00:25:07] JOS VOSKUIL:
Yeah. Yeah

[00:25:08] PATRICK HILLBERG:
Yeah. So. The German side of this company actually was where the real innovative thinking was going on. So there was once again, this this dynamic tension where on the US side and this wasn't a US German thing, it was more a matter of how this company was divided.

On the US side, they were really interested in what's the cheapest way we can get the project done on the German side. They were really interested in where do we want to be ten years from now? And quite frankly, it was the German side that brought PLM into the company. And the PLM that the American side is still using now was originated by the Germans. So you needed that innovative group of people that were not focused on margins in order to create the long term system that really drove margins. Let me let me briefly say, though, the Americans moved a heck of a lot quicker than the Germans did.

[00:26:03] JOS VOSKUIL:
Mhm.Right.

[00:26:03] PATRICK HILLBERG:
We made…

[00:26:04] JOS VOSKUIL:
Right.

[00:26:04] PATRICK HILLBERG:
We made a lot of progress very quickly on the American side.

[00:26:08] BEATRIZ GONZALEZ:
Okay, we are approaching to the end of the episode. But before that, before the wrap up. Josh, do you have any final questions for Patrick?

[00:26:17] JOS VOSKUIL:
Well, you know, my favorite question. It's particularly when you talk with experienced people. Experience is what you get when you don't get what you expect. So, Patrick, what is your best experience?

[00:26:28] PATRICK HILLBERG:
Yeah, I would say that the experience that I really want to take from this, and I bring this up in other places is the most important person in your PLM implementation, is the chief human resources officer. The chief technical officer is already there. The chief financial officer is already there. The VP of engineering is already there. The person who's probably not in the room is the chief human resources officer. And if she's really smart, she has a chief learning officer. And what you're introducing with this technology is a huge amount of culture change into your client organization. And the CHRO needs to be first. So that would be my my one piece of experience is bring in the CHRO.

[00:27:08] JOS VOSKUIL:
Put the person, the people in the center.

[00:27:10] BEATRIZ GONZALEZ:
Mhm.

[00:27:12] PATRICK HILLBERG:
Yes.

[00:27:12] BEATRIZ GONZALEZ:
Yeah.

[00:27:14] JOS VOSKUIL:
And to conclude this discussion, Patrick, what would you recommend? Or for the users or the people that listen to this podcast, what would they take away from you when you say, what is your next action point for them?

[00:27:27] PATRICK HILLBERG:
Uh, take my class. Right.

[00:27:29] JOS VOSKUIL:
Of course.

[00:27:32] JOS VOSKUIL:
Can they, by the way, or is it, uh, only open for a limited audience?

[00:27:38] PATRICK HILLBERG:
Actually it's an online course, and I'm looking to make it even more accessible so anybody can. I have students from around the world who take the class, so,

[00:27:46] JOS VOSKUIL:
Okay.

[00:27:48] BEATRIZ GONZALEZ:
…Patrick and we will add it in the comments of the podcast.

[00:27:52] PATRICK HILLBERG:
Yes. Yeah. Absolutely. Absolutely. No. That's terrific. Terrific. Thank you. Thank you for that, helping me with that outreach. So, actually the big thing I'm really interested in right now is systems engineering needs to sit on top of systems thinking. So if you don't have a good cultural organization which understands systems thinking, then your systems engineering really isn't going to work.

[00:28:15] JOS VOSKUIL:
Right.

[00:28:15] PATRICK HILLBERG:
So I'm very big on that process is you need to start with systems thinking before you can really implement systems engineering.

[00:28:24] JOS VOSKUIL:
Well, thanks…

[00:28:24] BEATRIZ GONZALEZ:
Okay.

[00:28:25] JOS VOSKUIL:
…for sharing. And I see we are a lot aligned also from what we see in our discussions on LinkedIn. It was a pleasure having you, Patrick.

[00:28:32] PATRICK HILLBERG:
Oh, this is so much fun. I love doing this sort of stuff. So thank you for asking me.

[00:28:36] BEATRIZ GONZALEZ:
Thank you very much. And thank you to our listeners. So if you would like us to discuss any topics in the following episodes, please write a comment and we will go for them. Thank you so much.