‘Dutch way of working’ will be challenged by the age of integration

When Wilhelm Claussen told his brother ten years ago that he was going to ramp up a manufacturing site in the Netherlands, he got laughed in his face. At that time, his brother ran a factory for building specialty machines in Germany, employing several hundred. His advice was: never manufacture in the Netherlands; you’ll only get individual parts made by individuals and sometimes they may even work.

“The general perception of Germans being more process oriented and disciplined and the Dutch being more chaotic and more creative has some truth in it,” Claussen admits when asked about the impact of cultural differences in projects. “I always appreciate working with Dutch people. They’re more daring, more inclined to look for opportunities, rather than coming up with reasons why something can’t work.”

Project leaders can benefit from both, Claussen argues, but you need to balance them. “Especially in development projects, you immediately recognize that there’s a certain period when you need to embrace change. In the beginning, you need creativity and you want to foster a positive drive for new ideas. Later on in a project, there of course comes a time when you need to make sure that you’re going ahead in a structured way.”

Trainer Wilhelm Claussen. Photo by Fotogen Fotostudio.

Can this chaotic behavior of the Dutch be a hindrance in projects?

“I wouldn’t say a hindrance. Wherever in the world you want to be successful in whatever project, you must always accept that the people in your team are the best people you can have at that moment. You have a goal, and you need to perform. The challenge is to get people moving in the same direction with the same pace, with the same sense of quality and with the same objective. That’s what you need to get going. For that, you need to utilize the cultural differences to make sure that the right person is in the right place in your project.”

So what did your brother not see?

“First of all, I think he was just nurturing his stereotype that Dutch are never able to run straight on a straight line. In that particular case, I was establishing a manufacturing process and that has always its own challenges. To get things done, you need to find the right contributor for each spot. That’s the same anywhere in the world. The bottom line is that our team succeeded, got the products out, outpaced all competition and were first on the market.”

But there’s an increasing challenge for the ‘Dutch way of working,’ Claussen warns. “When we look at current innovation processes in technology, most are combinations of known things. To make an innovation work in a product that’s useful for a customer, it needs to obey and follow a lot of already established interfaces because most of the time, we aren’t innovating, we’re mainly neatly integrating things.”

This is the age of integration?

“I think that’s exactly what we should call it, the age of integration. Even a fundamentally new invention needs to connect to a lot of interfaces and obey rules before it becomes useful for the customer. That means that you have to maintain a lot of discipline and structure before you’re actually rewarded with the benefits of new contributions.”

Why is that so difficult?

“Because it means that nobody can be an individual inventor anymore. Besides having a brilliant idea, which remains an individual act of creativity, the inventor needs to collaborate with a team of various people and disciplines to make the invention work. Every contribution nowadays is blending into an architecture with existing interfaces. That means the mandatory prerequisite for obtaining a working system is to understand how all the blocks or elements are working synergetically together with your new functionality, solution, idea or concept. For example, the first cars were made by only a few persons, visionary but lonesome inventors and investors. If you now look at a Daf truck, you see a system with a huge number of complex elements with interfaces that you must adhere to and operate with flawlessly. Lonesome inventors just can’t excel on their own anymore.”

And all basic elements are more or less invented?

“Certainly not. If you say that, you’re underestimating the creativity of some mad genius developer who comes up with some completely new concept. The point is that his new concept has to be integrated first to become useful. In engineering, we’ll keep on inventing new solution principles. I don’t think this will ever come to an end, but to integrate these and develop them into a product will become more challenging.”

And you presume that this is more challenging for the Dutch than for the Germans?

“Now, when I speak of the ‘Dutch way of working,’ I’m not referring to the Dutch as a people. I’m talking about a way of working characterized by a low level of displayed hierarchy, an accepted high degree of individualism and an optimistic and pragmatic attitude toward risk-taking on the way to new horizons that I’ve observed here in the Netherlands. It’s the same bold attitude that led the ancestors of today’s development engineers centuries ago to climb aboard small wooden sailboats – crazy, I say – and set out for the East Indies. That in itself is a very positive attitude. But in the age of integration, it must be accompanied by serious efforts at quality, structure and speed in system integration to turn an invention into a perfectly functioning, marketable product. And my observation is that the art of integration is a topic where we can learn from others, namely from the Asian environment. Our task in development in Central Europe will be not to lose the advantages of the ‘Dutch way of working’ and remain professional and fast in system integration. This will demand new qualities in project leadership to keep all that jazz in a healthy relationship with each other. That’s to say, Germans or whoever can also work ‘the Dutch way’ and will have to face the same challenges. I’m an example of this.”

Is inventing more like combining known technologies and is systems engineering getting more complex?

“I don’t like the word ‘complex’ because it’s a relatively unsharp term, often used in the context ‘being difficult and not clear.’ I observe that nowadays, we’re integrating subsystems to fulfill very specific purposes. That’s leading to a completely new way of managing product lifecycles and system integration requirements. I don’t see this race for complexity continuing endlessly. We’ll be building more for purpose.”

“For example: 25 years ago, automotive suppliers were building ten different water pumps for car manufacturers to choose from. They were attached to the motor using an external bracket and they were ready to go. Nowadays, each variant of a car type has a sophisticated supply chain for its own optimized water pump. If you’re buying a Volkswagen Golf with a combustion engine, there’s a pump for each variant of that engine. Bottom line: the component itself may get less complex. It can be simpler because it has to fulfill fewer purposes than each of the former ten variants of water pumps, which had to do basically everything.”

What’s driving this?

“The driving force behind this kind of segregation of variants is the fact that we’re using only the fully integrated products. Customers want a perfect car, not a perfect water pump. They don’t pay for that. That basically means the water pump needs to be just good enough for the user profile of the car buyer.”

When it comes to system design, there’s a big difference between building specialty machines and high-end consumer products like cars, says Claussen. In the consumer market, you can design the component lifetime. “The rear lights of modern cars are designed to work during the whole lifetime of the super system. You can’t exchange individual LEDs anymore, only the complete module. So, you must understand in detail the aging behavior and the major reasons why your devices fail – as part of your design and development process.”

In specialty machine building, Claussen says he has so far not seen anyone designing for reliability. “Designing for a certain lifespan of the complete system, I mean. When you buy plasma deposition equipment, an extruder or a wafer scanner, they’re built to be repairable and upgradable. As such, the chosen system architecture makes it possible to extend their life almost indefinitely. This is a system choice you must make deliberately and really early in the project.”

“A good project leader repeatedly asks the developers: what are the consequences for the customer who uses your product?” Photo bij Fotogen Fotostudio.

You and your development team need to understand from the very beginning what your product is going to be in the end?

“That’s why it doesn’t help if you just say systems engineering is getting more complex. You must consciously make fundamental choices on scales like ‘indefinite lifetime’ concepts versus ‘the first fail that kills the system’ concepts. And this happens very early in the project, when there’s still a lot of uncertainty and ambiguity.”

“Here, a good project leader comes into play. He needs to get the required expertise together on one table and has to drive his people into a corner where most developers are feeling uncomfortable, by asking them repeatedly: what are the consequences of your decision for the customer who’s going to use your product? Will it help him solve his problem? Is he going to be happy with it or not? Do the customer’s wishes match the product that you envision yourself?”

Why do developers feel so uncomfortable with that?

“When you look at conventional education, most of the engineers are taught to look downwards into their system. They’re experts in delivering detailed solutions to problems someone else gave them. Now, in the age of integration, we must turn this around to be effective and efficient with our solutions. When we turn it around and ask engineers whether they’re about to solve the right problem for the customer’s value, most will feel uncomfortable in the beginning. The good news is: I’ve never experienced that a smart engineering team isn’t capable of answering these kinds of questions once they embrace the importance of it and recognize the way to get there.”

So, a project leader has to recognize the kind of project he’s dealing with and set priorities accordingly?

“This is exactly what I expect from a good project leader. That he can slice down the problem. In doing so, he consciously identifies what is the right approach for which part of his project. If he can’t, it’s going to be a failure. If he can, it’s going to be a thrill ride.”

To explain what this means for project leaders, Claussen draws a comparison with dropping paratroopers. “When they land in a field after jumping from an airplane, they don’t start running in all directions. The first thing they’re supposed to do is look around, gather intel and understand where they are. That’s exactly what a good project leader does. The first thing is to make sure the people in his group understand where they are and where they need to go. That’s step one, always. If you obey that, I think it’s completely irrelevant whether you’re developing a water pump or an X-ray scanner. Because you bring into your team the persons with experience for making a pump or an X-ray machine. A project leader doesn’t need to have all the experience for that. I would even say it’s more important to have a well-developed awareness of your and your team’s limitations and blind spots. And of course, a methodology needs to be established to digest all relevant system architecture aspects before you start running. Then you may make very conscious choices for all different aspects within your system architecture, including reliability, performance, redundancy, repairability and so on. All these decisions have to be made at the beginning of your development. Providing structure paves the road to success. And if the development succeeds, it’s highly satisfying.”

This article is written by René Raaijmakers, tech editor of Bits&Chips.