Category: Interviews

At last year’s Sysarch conference, model-based systems engineering expert Jon Holt sat down with High Tech Institute’s Ger Schoeber to discuss the MBSE training. “In five years, all systems engineering will be model based,” according to Holt, currently the technical director of Incose UK.

 

With his black outfit, Jon Holt is more likely to be recognized as a magician than a system engineer. Actually, he’s both.

Let’s start with the magic. This is the stuff he uses to inspire. As a professional magician, he performs at music festivals and various science and technology events, using magic, mind reading and sometimes escapology to explain engineering principles. “We do things that are based on mathematics, science and memory techniques. I try, for instance, to explain to people how important visualization is, as a design concept.” He smiles: “There’s a selfish aspect. I enjoy it as well. Give me an opportunity to show off and I’ll take it.”

Jon Holt: “Give me an opportunity to show off and I’ll take it.”

Holt has also written a rhyming storybook based on systems engineering, aimed at children from ages seven to eleven. As the technical director of the International Council on Systems Engineering (Incose) in the UK, he works to raise that awareness together with professional bodies aimed at families with children. “It’s important that we don’t just think about where we are but also about the next generation of all engineers.”

Check out his training

Holt encounters a lot of misconceptions about engineering. “The term is very badly understood. Many people still think I fix things that are broken. Well, not quite. Engineering is seen as boring or not interesting. For me, that couldn’t be further from the truth. Look at the incredible systems we work on. Children can’t be separated from their mobile phones now. I’d like to get people to appreciate the engineering in that phone.”

Incose has identified Holt as one of the 25 most-influential systems engineers in the last 25 years. He’s internationally recognized as an expert in the field of model-based systems engineering (MBSE) and has authored 17 books on the subject. He’s also a professor of systems engineering at Cranfield University.

'In five years, all systems engineering will be model based.'

In Holt’s career, MBSE has played a central role. At last year’s Bits&Chips Sysarch conference in Eindhoven, he stated that all systems engineering would be model based in 2025. “If you go back 10 years plus, I’d spend all my time arguing with people if modeling is a good idea. At conferences, people would throw things at me because they didn’t want to model,” he recollects. But this has changed. “Now, the question is no longer: should we model? But rather: how do we model effectively and efficiently?”

Holt sees the shift in his work with large multinational organizations that have twenty-year-long product life cycles. “They want to shorten those cycles. Quality is obviously a concern, but their main driver for employing MBSE is to improve the efficiency of their processes. The human side of things comes into play as well. Companies want to make sure their staff has the appropriate skills and apply MBSE to that.”

Four changes in complexity

To explain complexity, Jon Holt compares the old Triumph Herald car he owned in the seventies with his most recent car. “The basic need is still getting from A to B, the human-machine interface is still a steering wheel, a gear shift and three pedals. But the complexity of these systems has changed over the last few decades.” He describes the change in four specific ways.
“The first way it has changed has to do with the system elements. They were 95 percent mechanical. Probably slightly under 5 percent was electric. In terms of the interfaces, the Triumph had mechanical interfaces and electric to mechanical. Very few were electric interfaces. Now we’ve also got electrics and software. With these elements come networking and communication protocols. We’ve got far more complexity.”
Next are the constraints. “The only safety measures in the old car were the seat belts in the front, and you didn’t even have to wear them – that was optional. There were no seat belts in the back. In terms of crash protection, the car was made of very thick metal. You just had to make sure that it was thicker than whatever you were going to crash into. That was safety back in the 60s and 70s. Today, you wouldn’t get in a car without wearing seatbelts. A modern vehicle has airbags, antilock brakes, and it will stop you from crashing into something else and from veering into another lane. The complexity has gone up. Not only because of the constraints, but because of the source of all those constraints like standards and legislation. All those best-practice models didn’t exist in the 70s.”
Third, is connectivity. “In my Triumph, the main type of connectivity to the outside world was me. Now the car is actually part of a wider system of systems. It connects to the cloud, to road signs, to the UK and European road networks, and talks with other cars. That comes with a whole new level of interfaces. I’ve got an app to tell me where my electric scooter is at all times.”
The fourth wave is the shift in complexity. “In my old car, the complexity was in the internal combustion engine. The complexity has shifted to the software. The mechanical complexity of a motor in a modern electric vehicle is very, very low, whereas the software complexity is very, very high. The software does all the control and it takes care of all the connectivity. Over the last few decades, the complexity has increased beyond recognition.”

Connecting engineers

Apart from that, working model based might also be the key to connect engineers. Here, we touch on the ambitions of Ger Schoeber, the chairman of Incose Netherlands, who we invited to sit down with us during the interview. Schoeber recently joined Lightyear as group lead systems engineering. He’s also responsible for systems and software training at High Tech Institute. In his past years as Incose chairman, he worked on bridging the gap between the engineering worlds of infrastructure and high tech.

Painting these two very different worlds in black and white, Schoeber says: “Engineers in public projects deal with contractors, subcontractors and contracts. Their focus is paperwork and processes, and the system comes second.” On the other hand, the high-tech industry is commercially driven. “There, the focus is time to market. Otherwise, they can’t compete and certainly won’t conquer the world. That’s why the approach is pragmatic and focused on the system, the product.”

Schoeber’s roots are in high-tech, but as Incose chairman, he observes that the Dutch chapter members typically work in infrastructure projects, building railways, roads and tunnel systems. “We have a big high-tech industry, but not many engineers know Incose.” The opportunity, according to Schoeber: “I’m sure that both worlds can learn a lot from each other.”

Single source of truth

MBSE is a common denominator, Schoeber and Holt agree. It can help high-tech to make even better products. The techniques that high-tech and civil engineers apply to develop systems and deliver them successfully must improve to cope with the added demands and complexity. The most common way is to apply model-based techniques. Holt puts it in very simple terms: “Traditionally, engineering relied very heavily on documents. For design, for understanding the requirements and so on. That worked very well for many decades. A perfectly good, solid approach. But as the complexity starts to increase, if all the knowledge, data and information associated with a system is split across multiple documents – and we’re talking thousands – just maintaining consistency is very, very complex.”

Ger Schoeber: “Most important is not the model, but to use common sense.’

In a model-based approach, all knowledge and information relevant to the system are kept in one place and kept consistent. “In that way, we have what’s often referred to as a single source of truth,” says Holt. “We can maintain that single source, and if done properly, that guarantees that the documents based on this single source of truth will be consistent. So rather than distributing everything throughout thousands of different documents, we’re bringing it all together in a single source of truth. For anything we want to know about the system, we interrogate the model. That’s where the information resides.”

Elaborating: “People say: a model can never be complete. Well, it doesn’t have to be. It has to be as complete as necessary to deliver our system. It can never contain all the information of the system. There’s got to be things missing, but that doesn’t mean it’s wrong. We focus on the relevant information to develop that system. It’s got to be useful and has to benefit what we do. If it doesn’t, then forget about it.”

Brontosaurus of complexity

To explain the impact of complexity on systems engineering, Jon Holt uses the brontosaurus theory problem. This theory is an analogy that states that the magnitude and complexity are directly proportional to the thickness of the animal. “At the beginning of a project, you look into the smiling face of the brontosaurus,” clarifies Holt. “The complexity is low, it’s thin at that point. You look at your requirements and think: yeah, that makes sense. You smile because it’s simple and the brontosaurus smiles back at you. You live in a very happy, if somewhat naive world.”
But then systems engineers come in with their cost, time and resource estimates. They start to apply their systems engineering principles. “They start modeling, identifying stakeholders, creating scenarios and while heading down the neck of the brontosaurus, the complexity goes up. When someone is showing you diagrams as big as a wall, you know you’ve arrived in the belly of the brontosaurus. Because although the diagram is very clever, nobody can understand it. And you’ve got people using all kinds of different methodologies and tools. Or even worse, using the same tool but slightly different versions that aren’t remotely compatible with one another.” Holt, from his experience: “All contractors leave at this point. Life is getting a bit too tricky for them. It looks like it’s the end of the world.”
But there’s a solution. “The problem is complex. It’s difficult to understand and almost impossible to communicate to all the different stakeholders. It’s very frustrating because as a systems engineer, you say: hang on, I’ve done this thing right, I’ve applied these principles, yet, I’m in the belly of the brontosaurus.” Then something interesting happens, says Holt. “Because if you continue to apply your techniques, the complexity is going down and down and down, to the tail of the brontosaurus – and this is our goal. And at the tail of the brontosaurus, you’ve got a concise, elegant solution.”

'As soon as you start to apply systems engineering and modeling, it gets more complex before it’s going to result in an optimal solution.'

Holt’s message: when you look at any kind of real problem, as soon as you start to apply systems engineering and modeling, it gets more complex before it’s going to result in an optimal solution.

The model and its views

The basic function of a model in MBSE is to communicate. It has to enable the system engineer to discuss the system in development with all its stakeholders, the financial department, the customer, the boss, the engineering team or some standards organization that wants to see if the system applies to all safety regulations.

For all those different stakeholders, there are so-called “views” (of the model). They’re the basic units in a model. Each of them is a collection of information with all the information a specific stakeholder needs to know about the system in development. Holt: “First of all, it has to be a valid view. If you can’t identify one of your stakeholders who would be interested in looking at that, then don’t do it.” Second, the stakeholder should benefit from looking at this particular view. “If you can’t answer that, it’s not relevant. It’s not a view.”

“If you imagine the model as a big amorphous blob of information, each view is like opening a tiny window into that model,” Holt continues. “We’ve got to make sure we open up enough of these windows to give us an understanding of the model as a whole. Because of the many stakeholders, we have to make sure that all views are consistent. Otherwise, it’s not a model.” He uses SysML as a modeling language, but in fact, you can use any language. It’s about doing it properly, to end up with a consistent model.

Holt uses models as a basis for the contract, for instance. “When companies in different sectors, like aerospace, power or the nuclear industry, put out a tender, they put out their specifications for the bids coming. What they actually do is putting out a set of views, which they submit as the technical part of their tender.”

The advantages are clear: “The model is becoming part of the contract. If four people bid for the tenders, they’ll have completed bids for the same set of views. For the customer, it’s far simpler to compare them than text-based descriptions, for example. The other advantage is that the set of views – the submitted model – actually then becomes a contract. Contractors will have to deliver on clear information.”

The high-level set of views in the conceptual level later become almost like the acceptance criteria for whatever is delivered. “This can be applied to infrastructure, as well as to more high-tech and commercial industries.”

Schoeber points out that the system architect or systems engineer plays an important role as the translator of the views in SysML to stakeholders without a technical background.

Appetite

Automotive is a good example of an industry that has developed a big appetite for MBSE, says Holt. “It started five years ago. The complexity has changed as time has passed. Compare an old car from 30, 40 years ago to a modern car and look at the complexity of the system elements, connectivity or the safety constraints. We’re seeing that the complexity has changed beyond all recognition. The techniques that we could apply to what was perceived as a modern motor car twenty years ago just aren’t good enough now. They aren’t rigorous enough to apply to a modern vehicle that’s part of a wider system of systems. MBSE gives automotive a competitive edge. If they don’t apply it, their competitors will produce better and more reliable products.”

Where does one start with MBSE? Holt points out it’s important to answer the why question. “If you can’t answer that, don’t do the work. It depends on the context. You have to ask what it is you’re looking to improve? What is it you’re setting out to do in the first place? It might have all kinds of emphasis, something commercial or things like quality attributes, a better product that’s safer, more reliable, more maintainable. Or look at security. You can steal a car by using a mobile phone, it’s crazy. The requirement to prevent that didn’t exist five or ten years ago. Now it’s becoming a standard demand from customers. There are no 100 percent autonomous vehicles yet, but we have driver assist, communication with road signs and collision avoidance to stop us from drifting between lanes. These are standard features, not optional extras in a modern car.”

Holy grail?

Is there a danger that MBSE is considered too much as a holy grail? Schoeber: “What worries me a bit is if we look at MBSE and all the tooling that comes with it, that we trust the tools too much. You have to make sure not to lose your common sense.” Holt shares Schoeber’s concern: “To think critically and question things is one of the systems engineer’s skills. We have to keep on asking why. You can’t bypass that.”

It’s also about managing people’s expectations, finds Holt. “Like any solution, MBSE isn’t a silver bullet. It’s not going to cure all our ills in one single shot. You have to know what you’re hoping to achieve, and very importantly, how you’re going to measure what you’ve achieved. Part of the problem is that people oversell the tools.”

According to Holt, the level of maturity in MBSE varies enormously between different organizations and industries. “Certainly in the UK. Traditionally, model-based systems engineering was always the domain of military, aerospace and later, rail. But now, if you look at the current roadmaps of automotive, they’re having a good time.”

Different industries also deal with different time schedules. Consumer electronics developments are shorter than infrastructure projects. Longer developments aren’t more relaxed per se, Schoeber points out. “The European Space Agency in Noordwijk has been using SysML for over 10 years. At ESA, a lot of countries work together to get satellites produced. You only have one chance for a successful launch. But on the other hand, they sometimes have to make tough choices when running out of time after 10 years of development. Then they have to decide: take the risk to skip some testing and verification phases to meet the launch window, or accept a huge amount of cost that comes with a year of delay?”

In the high-tech industry, Schoeber sees a playing field with many heroes, the creative and proactive people who take the lead in developments. “Look at ASML. That’s a hero-based company. But with a market share of almost 90 percent and enormously complex systems, they feel the need to do some processing and modeling in a more formal way. Otherwise, they won’t survive the next ten years.”

Are models replacing the heroes? Holt: “I think there’s always a need for heroes, but you won’t need anywhere near as many if you have a good approach in place. Often the heroes are there because things haven’t been done properly and they need to fight fires all the time. A lot of those things could be avoided. Space is a really good example. Until you fire your rocket into the sky, you don’t know what’s going to happen. You can put mechanisms in place to minimize the risk, but you can’t mitigate everything. Yes, you do need heroes, but we shouldn’t be relying on heroes for everything.”

Schoeber: “Most important is to use common sense. Systems engineers have to be brave enough to stand up and take responsibility. Because that’s what really makes a hero.” Holt: “It’s not so much that they have to meet the letter of their contracts, but rather the underlying intent.”

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

The profession of requirements engineering moves so fast that tool suppliers can barely keep up. “The software from major suppliers hardly takes into account the latest insights in our field,” says Cees Michielsen, trainer of System requirements engineering at High Tech Institute.

Customers becoming more central, systems becoming more complex and the design process becoming more and more intertwined. In a nutshell, these are the factors that drive change in requirements engineering. “Requirements engineering is out of its bubble,” says Cees Michielsen, trainer of system requirements engineering at High Tech Institute. “It’s now an integral part of systems engineering.”

“In the past, we only looked at the intrinsic value of a requirement. That’s also how the tooling was originally set up. In the meantime, we’re focusing more and more on what such a requirement does in the entirety of the product development. We zoom out more. Unfortunately, the software tools haven’t grown with us.”

In the coming months in Bits&Chips, Michielsen will highlight a handful of trends in his field. In this interview, we kick off with some of the topics he’s going to cover.

Major trends

Requirements engineering is about ensuring that customer wishes enter the product development process in a clear, unambiguous manner without losing information. That information can be very concrete: a 2,700-K, 350-lumen LED lamp. But it can also be vague: a comfortable truck. “We have to arrive at the right product,” notes Michielsen. “We have to implement what the customer wants in an efficient but correct way.”

Roughly speaking, Michielsen sees a handful of major trends in requirements engineering. For example, getting the requirements for a product complete is a perennial challenge for engineers. “It’s a recurring question from participants in my training courses,” observes Michielsen. There’s also a desire to increase the quality of requirements. Although not always exciting, this is a challenge for engineers because language and wording play a key role in drawing up good requirements and product specifications.

The increasing need for traceability could perhaps be called a truly new trend. “That term refers to being able to track all events and decisions in the requirements engineering, design and decision-making process, from stakeholders to product implementation,” Michielsen explains. “Conversely, it’s important, especially in larger projects, that for any requirement at any decomposition level, you know how to find your way back to the stakeholder’s needs. Why replace a side mirror on a truck with an exterior camera and a display in the cabin? You want to know why such a requirement exists in the first place and why it has the value it does. What should the features of that camera be, how large and what resolution is the display? What decision-making led to those specific values for that requirement?”

“A good requirements engineering process ensures that the stakeholder needs get to the implementation through the various development iterations without losing any information, including the intent of the customer requirement. Also, no requirements should be added for which there’s no stakeholder.”

Why is it so important to record not only the outcome of a decision but also the decision-making process?

“You want to be able to make changes to your product quickly and efficiently. To do that, you also need to know the reasoning by which you arrived at a solution. If you don’t record the decision-making process, you have to redo the entire reasoning process whenever changes are made. You have to go through the whole process again and start thinking again at a high level about what the proposed change means.”

“When you do record the decision-making, you save an awful lot of time. Especially in organizations that work with many product variants. When you know that an adjustment only has to do with the distinction between variant 1 and variant 2, you’re done much faster. You can work much more efficiently.”

That’s important when you’re making a hundred different shavers.

“Yes. For numbers like that, when you bring good traceability into your requirements engineering process, your administrative overhead is almost gone.”

Trainer Cees Michielsen

To Michielsen’s big frustration, almost all requirements tooling vendors substantially lag behind the reality in product development. Things like traceability and the relationships between requirements have hardly been filled in in the software tools of suppliers like IBM and Siemens. “It seems as if they’ve never studied the stages that requirements go through from stakeholder needs to implementation. The lack of a functional and physical breakdown of the system means that you can’t link the requirements to those specific system elements. You’re actually missing most of the functional and physical breakdown – the left side of the V model.”

“I think vendors of product lifecycle management tools currently have too limited a view of the role of requirements engineering within systems engineering. In addition, they don’t or insufficiently support the left side of the V model. For this reason, I think they’re unworthy of the title ‘PLM tool vendor.’ After all, they only support a limited part of the lifecycle.”

Could you give an example to explain what’s wrong?

“In the traditional way of working, engineers keep track of the extent to which each part or product is part of a functional module. Take as an example a bicycle handlebar of type X with an integrated bicycle bell Q in the handle of that handlebar. For bicycle handlebar type X, this is a fixed component. Bicycle handlebar type X contains bicycle bell type Q.”

“Assume that bicycle handlebar type Y has multiple options for placing a bicycle bell, including an integrated version. Bicycle handlebar type Y optionally contains bicycle bell type Q. Traditionally, we record the relationship between the object bike bell Q with the bike handlebars X and Y as characteristic information of bike bell Q. This results in the object bike bell Q having to be modified each time with each new relationship with a bike handlebar. The version or revision number, the status, and so on. In addition, all existing links must be checked. This means a large administrative overhead.”

“But this really isn’t necessary because the object bicycle bell Q hasn’t changed at all. Only the relationships between the parts have changed. The solution is relatively simple: make sure that the information indicating the nature of the relationship between objects is a conditional relationship. However, this capability is missing from current tools. The administrative overhead works through to the requirements, which also describe the relationship to other objects as an attribute. We’re talking about tooling from the big PLM vendors here! At the moment, they just can’t do it. So there’s still a lot to gain here.”

You say that big players like IBM and Siemens with their enormous development departments aren’t up to date?

“They sure aren’t, yet. The requirements engineering practice has made huge steps, but these haven’t been followed by the tool vendors. Even smaller players like Top Team, Cockpit and Contact Software aren’t there yet. That’s a big frustration.”

New tool vendors have a market to conquer and should be motivated to add functionality.

“They don’t do that enough yet, while as newcomers, they do have the flexibility to do so. The Dutch company Relatics from Ridderkerk is a supplier that’s doing well, but they’re mainly focused on civil engineering and not mechanical engineering. Relatics has built its whole tool around semantic modeling, where you consider the whole world as objects and relationships between them and all the attributes that go with them.”

Requirements engineering also influences the way we look at product creation. In high tech, people often refer to the V model when they talk about the process from initial ideas to product implementation. This model starts with a functional breakdown, the left leg of the V. Michielsen: “A practical problem is that you can’t include all requirements in the traditional functional breakdown. That applies, among other things, to the physical properties of products. Mass, volume, that sort of information. It would be wise to start two parallel trajectories in that left leg. Because later it will turn out that in the ascending leg, when you integrate, you can’t test what you’ve specified. This occurs, for example, when a submodule or function is distributed or divided among several physical modules. In that case, you can’t test those particular subsystems as separate modules, one at a time.”

The subsystem can only be tested once the entire machine has been assembled?

“You would like to be able to test such a feature right at the start, but indeed, that doesn’t work. You then actually need two parallel development trajectories, including the responsibilities and budgets that you can allocate to them. Before you have anything made or assembled at all, you use simulation tooling to do a virtual functional integration and a virtual physical integration. The goal is to first establish that the design is correct. That everything works and everything fits.”

“When you get to the end of that virtual development, you also know exactly that you’ve developed the right building blocks. You’re complete with respect to functionality. At the same time, you also know where those building blocks end up in the different physical modules because you can demonstrate that through your physical design. Once it fits virtually, you start implementing, constructing, programming, and so on.”

The W model, as Michielsen calls this form of development, will be the topic of a separate episode in his trend series.

The system requirements engineering trend series is also available as Bits&Chips podcasts on Apple, Buzzsprout and Spotify.

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

Last November, Jan van Eijk received the 2021 ASPE Lifetime Achievement Award from the American Society for Precision Engineering (ASPE). As one of the driving forces behind the Dutch mechatronics industry in recent decades, Van Eijk has left his mark on the Americans as well. In this first of two articles, we look back at how he gained a foothold in the US with Dutch knowledge and knowhow. Jan van Eijk is co-founder of Mechatronics Academy, providing all mechatronics trainings for High Tech Institute.

 

Jan van Eijk typically reacts soberly when Mechatronica&Machinebouw congratulates him with the Lifetime Achievement Award from the ASPE. “During the award ceremony, I pointed out that I see it as a token of recognition for the quality of mechatronics and precision technology in the Netherlands. I was sent to the US as a delegate about twenty years ago to develop relationships. This award is an appreciation from that professional group in the US that we have achieved considerable quality and effectiveness in that area in our region. I just had the pleasure of representing the Netherlands.”

Van Eijk is downgrading his own achievements a little bit. After all, it is by no means evident to convince the Americans of our qualities in mechatronics and precision technology. Van Eijk still remembers his first presentation at an ASPE conference in 2001. “On behalf of Philips, I had to ensure that we would play a role in that community.” Van Eijk bought a three-piece suit for the occasion. “In the American technical world that is very unusual, so everyone knew straight away that there was a weird guy walking around”, he laughs.

 

“Dare to climb out of your foxhole and explain yourself”, advises Jan van Eijk. “It will give you a valuable view on your own work.”

 

In his presentation, Van Eijk emphasized the differences between the Dutch and American cultures. “At that time, KLM was negotiating a possible merger with an American airline. They didn’t get anywhere because the styles and cultures clashed. The focus on quick money with the Americans against the long-term vision at KLM”, says Van Eijk, who then dropped a bomb in his audience. “I said, “I was sent here to cooperate with you, but I think it’s a mission impossible because Americans and Dutch can’t do that at all.” Van Eijk had made an unforgettable first impression.

He hastens to say that it is not all so black and white. “Of course there are executives and engineers in the US who prefer the long term over the fast buck. We sometimes have that image of Americans in the Netherlands, but in practice it turns out that it is not too bad.”

However, Van Eijk’s deliberately provocative comment does make sense. He based himself on research by the Dutch organizational psychologist Geert Hofstede, who mapped different cultures in the world along six dimensions. One of those axes revolves around long-term thinking. The most recent data from research agency Hofstede Insights shows that the Netherlands scores 67 out of 100 points in this area, and the US only 26.

Alpha males

An important reason why the Dutch excel in mechatronics – “no, that isn’t arrogance”, according to Van Eijk – is linked to one of Hofstede’s other dimensions: masculinity. “The way in which we work together in the Netherlands is fairly unique in the world”, explains Van Eijk. “Norway and Sweden are pretty close, but otherwise most countries score much higher on the masculinity axis.” Hofstede Insights gives the Netherlands a 14 on that axis, compared to a 62 for the US. “It’s about behavior within companies, about wanting to be the main guy. In American companies, it is appreciated when a boss is masculine, decisive and self-aware. It must be a macho, maybe even a bit of a bastard. In the Netherlands, soft elements such as empathy and a collaborative approach play much more important roles. In this, we are drastically different from many other countries. If someone here calls me “Mr. Professor” I think I’m being tricked, when even across the border, in Germany, that’s common practice.”

The typical polder approach, the consensus-oriented way of solving problems, is an excellent starting point for mechatronic design, says Van Eijk. “When you want to find the best solution, you have to work together at a high level because of the multidisciplinary character of the field. You need specialists in electronics, control engineering and mechanics. But when they all want to be the alpha male, it won’t work.”

“When you want to find the best solution, you have to work together at a high level because of the multidisciplinary character of the field.”

It is a wise lesson that Van Eijk learned from another Dutch mechatronics guru: Rien Koster. In the mid-eighties, Koster started an ambitious project at Philips. His idea was to pull the super specialists from the various disciplines out of their cubicles and have them work together on a mechatronic system. Fast and Accurate 86 (FA86) the project was named. The plan seemed a guaranteed success, but in practice the top players from mechanics, electronics, control technology, software and metrology only quarreled. “They all wanted to be the top dog”, says Van Eijk.

After a year, Koster pulled the plug and started over, but this time with a much better awareness of the challenge that when you put all those alpha males together, cooperation does not come naturally. In the end, FA86 delivered the FAMM robot, a two-armed system with gigantic direct drive motors that you would normally find in a submarine. The FAMM (‘fast and accurate manipulator module’) was so strong and so fast that other robots were pale in comparison. Unfortunately, the industry was not waiting for such an expensive solution to a problem that they could also solve with twenty small robots.

Out of your foxhole

Despite the technological success, Koster took that experience to heart and made it one of his missions to change the culture. “The general trend in the Netherlands at the time was already moving towards collaboration, but top technical specialists were eager to show that they were the best. That is how they were trained”, says Van Eijk, who still wholeheartedly endorses Koster’s vocation.

A result of the mission work is the mechatronics training that started at Philips in 1989 – and the mechatronics trainings can still be followed at the High Tech Institute. “The main message of that course is that if you want to do proper mechatronics, you have to collaborate closely”, says Van Eijk, who has instilled that idea as a teacher on nearly two thousand students. “In the introduction I always say that I have no intention to turn a mechanical engineer into a control technician, or vice versa, but that I hope that afterwards they will respect each other’s field of expertise, be curious about the challenges of the other, and dare to climb out of their foxholes to explain themselves, and thereby do the valuable exercise of looking at their own work from a distance.”

Check out his training

This Dutch approach is also highly valued in the US. According to Van Eijk, knowledge sharing is one of the main contributions of the Dutch high-tech industry to its American colleagues. “Of course you have a lot of American super specialists in the field of mechanical design, but they are really interested to hear that different approach”, says Van Eijk. “In the US, it is not customary to take courses such as our mechatronics trainings. It’s starting to happen a little around ASML’s San Diego and Wilton locations now, but other tech companies won’t be sending their employees to a course on a regular base. Tutorials are therefore given prior to an ASPE conference, for example, in which many Dutch specialists have already transferred our approach in bits and pieces.”

Along this technical axis, Van Eijk – with the help of various other delegates such as Adrian Rankers, Theo Ruijl, Ton Peijnenburg, Dick Laro, Leon Jabben, Dannis Brouwer and Piet van Rens – has managed to build up good relations with the American mechatronics sector. Van Eijk: “They became increasingly curious about what is happening here in the Netherlands, visited us, attended conferences and now there are many partnerships with companies in the region.” Van Eijks Lifetime Achievement Award is a token of appreciation of that sector for the knowledge that American mechatronical engineers can get here.

This article is written by Alexander Pil, tech editor of High-Tech Systems.  Trainer Jan van Eijk. 

Going from an engineer into a leadership role is anything but straightforward. The biggest challenge for technical minds, according to High Tech Institute trainer Jaco Friedrich, is to align and influence diverse and multidisciplined stakeholders – all from a position without power. To Friedrich, generating this buy-in doesn’t only come from your technical expertise, but from proper positioning, strong leadership skills and good communication.

 

You’ve finally done it. After years of working your way up from junior to senior engineer and architect, now you’re ready to take on a leadership role. This is your chance to show the company that you’ve got what it takes to assume the wheel and drive a team to success. With all the technical knowledge you’ve gained through your experience, you’ve pretty much seen it all and are quite advanced to less-experienced team members. This transition should be a breeze, right? According to Jaco Friedrich, a former architect and team lead turned trainer, establishing your technical credibility can be a big help, but it’s your leadership skills that will bring you to the next step in your career development.

“Spending years working my way up through the different levels of engineering and then to group leader, I’ve experienced first-hand the difficulties and the pitfalls of making the jump to a leadership role,” recalls Friedrich, a training expert at High Tech Institute. While the high-tech domain is filled with some of the brightest technical minds, for many, it’s the non-technical soft skills of interaction and communication that are lacking. “It took me years of training and education to really understand those difficulties, which is why I use my time to share what I’ve learned with the engineers of today. Sometimes, you can best teach that which you most needed to learn in your own personal development. I think that’s definitely the case for me.”

For the last 20 years, Friedrich has put his focus into teaching and helping engineers grow into leadership roles. He has trained thousands of engineers and architects, in the Netherlands and abroad, to learn the skills he wished he possessed early in his career. This includes his High Tech Institute’s two-day training “Leadership skills for architects and other technical leaders.”

Check out his training

Call your bluff

In his experience as a trainer in high tech, Friedrich notices that engineers have two main challenges, or dilemmas, to overcome when moving into leadership. The first is that leaders are expected to plan or take a specific direction earlier in the process, which means making big decisions with only a limited amount of information and clarity. “What I see is that engineers are very technical at heart. They might be 80 percent comfortable and have an idea of the way to go, but they hesitate because making big decisions without 100 percent certainty can feel daunting,” suggests Friedrich. “The problem is, someone else in the group might only understand 30 percent but be much more vocal, and this often leads to the project being steered in the wrong direction.”

The solution, Friedrich says, is not to be afraid to take a position, even if you’re not fully certain. Instead, start by conveying what you know and pointing out the potential risks. This invites everyone into a dialog and allows the group to assess risks and rewards.

“You never want to be fake in these situations. Your colleagues will call your bluff and certainly won’t buy into what you’re saying,” explains Friedrich. “In this scenario, it’s really about positioning yourself and being open from the start. Being a leader means you’ll find yourself no longer in the world of science but in the world of risk management. It’s a real mind shift that has to take place.”

Trainer Jaco Friedrich.

'To really make the jump to become a leader, you have to find ways to create headspace.'

 

Headspace

The second dilemma, according to Friedrich, is finding the right balance between the engineer’s mentality of finding solutions on your own and finding ways to delegate responsibilities to keep a broad view of a project and its stakeholders. “This is one of the more difficult shifts for engineers going into leadership roles. They still want to work like they always have but can lose sight of all the moving parts and pieces,” illustrates Friedrich. “To really make the jump to become a leader, you have to find ways to create headspace. This means you must learn to delegate tasks to others and then help by coaching them through the process.”

Friedrich points out that while your technical knowledge is a great asset to help guide these situations, coaching relies more heavily on patience, communication and an entire set of soft skills. “To be effective as a leader, you’ll need to find a way to really develop skills in diplomacy and influence to gain buy-in from the various stakeholders,” he reveals. “Teams today are extremely diverse in terms of culture and discipline. To get all the stakeholders on board with the direction you’re steering means knowing how to appeal to them and motivate them from a position without power. Formal power can be effective, but it’s certainly not a motivating force.”

Resistance

Of course, no matter how sharp your influencing skills are, it’s not always possible to win everyone over. When you’re working with diverse groups of highly intelligent, highly technical people, you’ll most certainly run into different levels of resistance. Learning to deal with this resistance is crucial to being successful in a leadership role – and is one of the focal points of Friedrich’s training.

“Something that a lot of engineers struggle with is how to turn resistance into positive momentum. In our trainings, participants are always stumped to learn that as much as 50 percent of that resistance actually stems from themselves,” teases Friedrich. “It typically comes from one’s inability to present information, options and consequences in a clear and meaningful manner. We teach some simple tactics for new leaders to maneuver themselves into a position of strength and clarity from the start. That way, they can avoid wasting time getting the ball rolling. Of course, there’s still the other 50 percent, but to learn that you’ll have to come to the course.”

 

This article is written by Collin Arocho, tech editor of Bits&Chips. Trainer Jaco Friedrich. 

How does a project leader cope with busy bosses, square techies with big egos, system architects and lonesome inventors? In the tech world, this is made easier by the common rule set of physics that everybody agrees to, according to Wilhelm Claussen. He also shines some light on his project leadership course at High Tech Institute.

Wilhelm Claussen can tell you everything about what it means to be a project leader and how to get to success with your team. But there are more angles to project leadership. You also have to ‘influence without power’: keep higher management involved and stay connected to peers like system architects. Project leaders have to be aligned to stay on the right track.

Starting with the upper layers, Claussen immediately dims high expectations. “Having been in higher management positions, I can tell you that there you have very limited insight in the projects that are running, as you’re constantly being tossed around by the various calamities.” That’s why it’s crucial that project leaders understand how they communicate upwards, he says. “You need to do that in a way that people above you can hear and understand you. It’s the first step to be helped.”

Claussen points out that it’s extremely important to have a relationship with your project sponsor or customer. “That of course builds over time. The question then should be: how do you build this relation? Communicating with management follows the same rules as communicating with your team. The main point is: be consistent in your communication. In short, for management, you must come across as straight and reliable. And you have to achieve, but that’s the name of the game.”

As a mandatory prerequisite for consistent communication upwards, Claussen mentions that the project leader himself needs to be aware of the actual project progress. “You have to honestly answer the question: am I on track or am I not on track? You shouldn’t accept bad quality in your project, just for the sake of ticking off a box in time, because this is going to haunt you. Better limit the number of boxes to be ticked in the beginning, by using a smart project setup. Otherwise, this is going to fall back on you much, much later. It’s pretty much like the statement accounted to US president Eisenhower: ‘No one has time to do it right the first time, but everybody has time to take a second look and do it over again.’”

 

What if problems arise or things really go wrong?

“Then you need to be clear and communicate bad news to the management and sponsors above you. And you must take painful decisions, in a courageous and well-balanced way, as early as possible. People have the strange tendency to close their eyes and avoid a bold decision because they might be wrong or they’re afraid of the consequences. But with every delay, you’re driving further to the cliff.”

“A very funny Roman saying goes: it’s better to be the fool of all the people than to postpone a decision because you’re afraid of becoming a fool. Yes, decisions can be wrong. Did I make the wrong decisions? Of course. But the moment you recognize that you made a wrong decision, and if you have a good track record in your project team, you can stand in front of the group and say: ‘Sorry folks, the last four weeks, we were marching in the wrong direction. By the way, yesterday evening I recognized that. This is why we’re changing today. We’re now heading for that direction.’ If you have a good team, they’ll turn with you as one man.”

After getting some headwind…

“Not at that moment, if you’re working with professionals. The worst will come next Christmas party because then everybody will make jokes about you, but that’s the price you have to pay.”

Trainer Wilhelm Claussen. Photo by Fotogen Fotostudio.

Other rules?

“Similar to the communication with your project team. Like being extra careful with silence. If you don’t hear anything from a particular stakeholder, project sponsor or supplier, it doesn’t necessarily mean that it’s good news.”

 

Do you have experience with that?

“You call it experience, I call it failure. I remember our team in Korea was waiting for a turbo booster pump shipped from our parent company as the critical delivery to the production start of a newly built factory. The agreed delivery date came and we all went to the airport to pick it up. But when the airplane landed and the hatch opened, we were staring into an almost empty cargo compartment. No pump. Only then, when I furiously called my sponsors, they told me it would arrive three weeks later as they had rerouted the device scheduled for us to some other construction site. And of course, the sponsors did know about that issue earlier but failed to communicate that. So, when the project part – in this case, my superiors – doesn’t inform you about flaws ahead of time, it deprives you of all options to counteract. That’s why you have to act yourself if you don’t hear anything.”

Does that require a specific character?

“I’ve seen lots of different characters that were good project leaders. I don’t think a specific personality is required. Of course, you have to like dealing with the unexpected and making things work. But the weak spots that arise in projects are always pretty much alike and rarely related to the character of the project leader alone. It’s usually a sequence of events that leads the project into the ditch. Failure is also a team effort. The good news is that you can learn to prevent it. If you keep an eye on those essentials and develop a sensitivity for your blind spots, you can make sure that your project has a much bigger chance of success, regardless of the chosen method or methodology or your personal character. That’s also what I transmit in my course at High Tech Institute.”

In high-tech companies, project leaders operate very close to system architects. What’s their relation and how do their tasks differ?

“For me, system architects are the caretakers and wardens of the functional integrity of the system throughout all levels. The project leader is the person that concerts, aligns and coordinates the work along a timeline to make the functions of the system available to the customer. I have very good experience in dealing with system architects. The project leader will provide them with the environment for decision-making, for example with discussions in change control boards, supporting and structuring their requests and allowing them to process their input according to an agreed rule set. The technical decisions I basically leave to them: which functions or features to include or exclude. But I hold them accountable for the technical content, for following the rules and for proper alignment. No lonesome cowboys!”

Can you tell a bit more about the interaction with architects? Presumably, there can be heated discussions sometimes.

“For sure, there can be heated discussions. It’s important to manage these people as well as the technical subjects in a well-balanced manner. Let me give you an example. I once had an issue with one of my piping architects. Through a lonesome design change, he managed to increase the amount of excess heat that had to be removed from the system literally overnight by almost 30 percent. When I challenged him on this in the team meeting, he basically replied: ‘I’ve done that because it’s necessary; you wouldn’t understand anyway.’ At that moment, the communication went completely out of control. I intended to make him explain his measures to the other architects and follow the agreed rule set for alignment. He understood this as ‘this guy is challenging my expertise’ and in return challenged my position as project manager.”

How did you resolve the miscommunication?

“Well, this is the funny part. First, I was about to jump on him, but fortunately, the miscommunication became clear to me just before I did. I started laughing, and after my explanation, he cheered up as well. He then wrote a note to his colleagues, giving the details of and the reasoning behind his design change. In the CCB meeting the following Friday, he got consent from all stakeholders in the project – for a good contribution that had almost ended in a bitter fight.”

Photo by Fotogen Fotostudio.

In technical environments, some people are more square than others. Is that a challenge for a project leader?

“I don’t think so. We’re privileged to work on technical stuff with other educated people. At the end of the day, we have an objective rule set that everybody agrees to and that’s called physics. As long as everybody agrees to this rule set, you’ll always have an objective way to settle a technical dispute in a development project. Sometimes, of course, it can bend a bit left and right before finally coming to a conclusion. We’re blessed that there are no alternative facts for physics. Or to cite the Nobel prize winner Richard Feynman before US Congress when NASA tried to cover up the Challenger disaster: ‘Physics doesn’t care about marketing.’”

Do projects in the high-tech region around Eindhoven differ from an environment like the automotive industry in Germany?

“I think they’re both high-tech, highly integrated, both are hardware driven with a strong software component. From that perspective, they’re relatively comparable. In general, the major differentiator is between realization projects and development projects. In a realization project, you usually have a clearly defined achievable goal, a lot of manufacturing people who are used to following orders and performing tasks in a structured way – you ‘just’ need to get it done in time. Development environments are more interesting. There, the path to success is less clear and even the goal is sometimes uncertain. And you’re dealing with developers, usually very intelligent individuals, who perceive themselves as hidden geniuses – some of them really are. In this case, the leadership challenge is to include them all in the common goal. For that, you have to lead them, guide them, motivate them to deliver a concerted action.”

 

Some of them will work on a new functionality every day if they have the chance.

“And if they do, you have to cope with it constructively. By asking yourself: is this benefiting my customer, is this fitting into the integration? You actually have to foster this in the early development phase. Because this is your only chance to make a product that’s different from what’s already existing.”

But you have to be very careful with that?

“Yes, I can fully subscribe to that. You must balance it in a structured way. I always rely on the technical experts and architects in my team. They make a balanced and structured assessment of this new idea to incorporate it, yes or no.”

Your new course at High Tech Institute is focused on project leadership, not on project management.

“The reason to focus on project leadership is that project leadership is the art to influence the pace, focus and goal of the project. Along the way, you provide guidance and insight to the team. You have to be the man on deck – that’s what project leadership is about. Project management is the set of means and methods to have a transparent, clear and structured communication and framework. It’s a kind of a basic condition.”

You teach this course in one day. What do participants take away?

“I don’t like the word ‘teaching’ when it comes to leadership. This course is designed for people who already have project management and project leadership experience. I prefer to say that I’m sharing the essentials I’ve gained over the last twenty years in high-tech project management. Participants will be taking away a fresh and independent view on how to manage their projects better, by focusing on a few aspects to make sure that they’re followed. It’s not a project controlling course. The key to success is to not lose the overview and I show how to keep that overview in a complex and fast-changing environment.”

This article is written by René Raaijmakers, tech editor of Bits&Chips. Trainer Wilhelm Claussen. Photo by Fotogen Fotostudio.

Dynamics plays a key role in overall system performance. Design choices can have severe consequences. Therefore, it is important to choose the right direction from the start and to substantiate the concept with modelling techniques. “You have to take into account all your forces and interferences, and position the sensors and actuators correctly. Trainers Dick Laro and Adrian Rankers ellaborate about their Dynamics and modelling training.

With each successive generation, the bar for high-tech machines is raised. The new system should move faster or more precise. Design choices from the original development process might turn out to be unfortunate. Eigenfrequencies and vibrations, which were still negligible in the first machine, suddenly put a spanner in the works. At an precision requirement level of typically around ten micrometers, it becomes a real challenge to keep the dynamics of the system under control with standard design rules.

Designers may still know dynamics theory from school, may even have done some calculations, but they often lack the know-how to translate that knowledge into their current physical machine design. “How does the dynamics relate to errors in the system and to the stability problems in your control loop? How do you model that? And how can you then use those models to achieve a better system?”, says Dick Laro, system architect at MI-Partners and teacher at High Tech Institute. During the training ‘Dynamics and modelling’ (DAM), students receive answers to these questions. “We make the link between theory and practice, and between the various subdisciplines. How does the dynamics interact with control technology? And how does the mechatronic design fit in that picture?”

Laro and co-teacher Adrian Rankers use the practice of starting small and simple, and expand later. “I always begin with a bottle on a rubber band – a very basic mass spring system”, says Rankers. “If you understand the basic dynamics of this, you are already well on your way. Then, you have to understand how to describe vibrations of more complex objects.” He takes a sheet of paper, starts bending and twisting it, and says: “There are all kinds of mode shapes in this; shapes that you can describe using modal analyses. In order to design a stable system, you have to understand it, see that one point moves faster than another and that there are even points that move in the opposite direction. This has consequences for the actuator and sensor location, among other things.”

Interferences

According to Rankers, there are two reasons why it is so important to understand all those mode shapes down to the last detail. “One side of the story is that vibrations lead to accelerations and thus to forces. They can seriously hamper your control. Moreover, when two connected parts move with each other, a force is transferred. But that transfer is never 100 percent; there is always some distortion in those parts, certainly at the micrometer and nanometer level.”

“The other side is that in all systems you have to cope with interfering forces,” Rankers continues. Think cables that keep vibrating, friction, all kinds of forces from the process and of course external disturbances such as floor vibrations and acoustic excitation. You have to take all those forces into account. “And every force has a counterforce. A stage pushes against a machine frame that gives back a reaction force. After a while, the two of them are shaking happily.”

When you know all those disruptive forces, you want to control them. “With an expensive measuring system you can accurately determine the relative position of objects. Then you try to straighten things out with corrective forces,” explains Rankers. “You want to do that with a frequency as high possible, and as rigidly as possible. That means a high bandwidth in your control loop. Then you have a stiff coupling between those two objects. However, there are limits that are determined, among other things, by instability in the control loop. And it is precisely those vibrations that can make control loops unstable.”

Magic words

The ultimate goal is to provide insight into all vibrations in a system. “From modal theory you can describe all complex mechanical systems as a sum of a mass-spring systems,” says Laro. “Some have a phase that matches, others move in the opposite direction, making the dynamics more difficult. Still, you can build the larger system from easier-to-understand subsystems. We explain how you do that in the course.”

Dick Laro.

FEM tools are perfectly capable of calculating the modes of those subsystems. “That’s nice, but you don’t design a machine based on mode shapes,” warns Laro. “It is certainly not obvious how to link those sub-results back together. How does that mode shape relate to a transfer function and a system error? How do the mode shape and the eigenfrequency relate to the bandwidth? And more practically, where should I place my sensor and actuator to be able to suppress that one disturbing mode?”

Rankers answers the last question: “It will probably sound as a no-brainer that it is a good plan to drive a system at the center of mass. But that isn’t always an option. Perhaps there is an optical element in the way and you have to let the force apply to one of the corners. Is that okay as well and what is the effect on overall system stability? And where will you measure? Perhaps diagonally opposite might be best because you are close to the point of interest there, for example close to the wafer. Then you do not necessarily measure at the place where you actuate the system, so you are confronted with all kinds of modes that increase the chance of instability.”

Adrian Rankers.

“You will need to model the system in order to estimate whether or not your design choices are allowed,” Rankers continues. During the High Tech Institute’s ‘Dynamics and modelling’ training, participants experiment hands-on in the 20-Sim simulation package. Laro: “How bad is it if I don’t actuate in the center of mass but an inch off? How far can you go and what happens if you go too far? Modeling and evaluation, those are the magic words, because it is very easy to mess things up.”

Rankers again: “You always start with a list of requirements and wishes, nothing more. Then you need to carefully consider what the right choices are and what you can better avoid. In that respect, it is a knockout race. Because you understand what happens in the dynamics and how you can correct for any disruptive forces, you can make a good assessment at an early stage. Some ideas look better than others, so go with those. In 2D, in 3D, until you get to the finite element analysis. That is why you optimize the system, but you can’t solve choices with it that are fundamentally wrong. On a conceptual level, your design has to be good.”

Four essential tips

1. No component is infinitely stiff. A block of metal and even a chunk of granite have internal mode shapes and can deform. A rule of thumb is that if you want to achieve a bandwidth of 200 Hz in your control loop, all other vibrations – including the internal ones – must have a higher frequency by a factor of 10.
2. A guide does not have infinite stiffness either. In any case, you don’t want to rely on that stiffness at all. In a linear system this means that you want to actuate in the center of mass. Actuate the part so that it does exactly what you want even in the absence of that guidance.
3. Think about the mass proportions. In the CD-actuator, for example, that turned out to be a nightmare. In the first generation everything was bulky and there was no problem, but in later generations there was a considerable challenge because the mass of the part that had to move aproached the mass of the ‘fixed’ world.
4. Be aware of the reaction forces. The force you use to drive the stage, for example, always has a counter force. That force goes to the machine frame and probably also to the sensor block that is attached to it. In short, you excite the sensor block through the reaction force. And a vibration of the sensor block can be seen in the sensor signal just as well as when the stage moves. So you have to include the full reaction path.

This article is written by Alexander Pil, tech editor of High-Tech Systems.

We’re working in the age of integration, where lonesome inventors can only make an impact with a good team. In this second interview, Wilhelm Claussen, project leadership trainer at High Tech Institute, talks about the changing environment of system integration, how cultural diversity benefits project teams and the challenge he specifically sees for the Dutch.

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.

Taking a swing at his 3rd career opportunity, High Tech Institute trainer Kees Rijssenbeek has found his cup of tea and his calling. Now, he’s putting his energy into helping technical minds navigate challenging social interaction and giving them the tools, and knobs, to help them fine-tune their approach.

After a few years of trying his hand at mergers, acquisitions and employment law with the Dutch office of the US-based multinational law firm Baker McKenzie, Kees Rijssenbeek realized that corporate law just wasn’t his thing. “In hindsight, I guess you could say the company was much clearer on it not being my cup of tea – more so even than me,” recalls Rijssenbeek jokingly. “In law, you either move up the ladder or you’re out. And while I was just starting to entertain the idea of becoming a partner, it turns out the firm didn’t share the same vision, so out I was, along with about two-thirds of my colleagues.” Rijssenbeek continues, “It turned out to be a blessing in disguise. Looking back, the 80-hour work weeks with troves of legal paperwork was never going to make me happy.”

Kees Rijssenbeek: “I came to the realization that the most exciting and interesting part of any of my jobs was the personal human interaction.”

For his next move, Rijssenbeek had a go at the retail domain, where he contributed to the marketing and commercial team of the cosmetics brand Rituals. This was during the brand’s early days, when it was just working to make a name for itself and had only one office in Amsterdam with about ten employees. “While it was a big change from corporate law, I found I was having the same kind of feeling. For the most part, it was just a job and didn’t really give me any energy,” remembers Rijssenbeek. It was then that he began thinking about what would motivate his interest. “I started to take some personal training courses in my free time to discover who I was and what I wanted. I came to the realization that the most exciting and interesting part of any of my jobs was the personal human interaction.”

“Looking back at this part of my life, I realize two things. First, I’ve always been interested in learning about people and I’m good at listening and truly hearing what they have to say. Of course, it was coming to the business of training that helped me come to that realization,” suggests Rijssenbeek. “The second thing is, I really should have purchased shares in Rituals way back when it was so small. I guess we learn a lot of things in hindsight.”

 

Jealous

Now in the professional training domain for the last ten years, Rijssenbeek seems to have found his calling, or his cup of tea, as it were. Three years ago, he joined the High Tech Institute team where he delivers the training “Effective communication skills for engineers” aimed at helping technical people master some of the biggest communication challenges and pitfalls. But it’s working with this particular audience of highly technical people that leaves him a little envious.

“Not to generalize too much, but something I notice in many technical people is that they have a few traits that I’m pretty jealous of. One is that they’re pretty humble and have good insight into the limitations of what they know and what they don’t yet understand, be it in the laws of nature, the laws of physics or beyond. They’re also wired with a very real desire to solve problems,” illustrates Rijssenbeek. “There’s sort of an absence of the whole political way of dealing with each other. They’re interested in, does it work? If it does, great, we’ll use it. If it doesn’t, then it’s right back to the drawing board to find a solution. It’s not about getting all the credit. That’s certainly not the case in business law and marketing.”

 

Knobs

That said, there are also some common obstacles that prove to be a challenge for many technical people, especially in communicating. For instance, spending a lot of time in circular conversations and getting nowhere, having trouble getting buy-in from stakeholders or coming off as too critical when delivering feedback. While in the technical world most issues can be quantified and calculated, using data to make assumptions, when it comes to personal communications, it can be a little more challenging if you don’t know what cues to pick up on. And it’s to this end that Rijssenbeek looks to help guide training participants.

“From miscommunications to personal life issues to people just having a bad day, there are a number of factors that affect interpersonal communications. What this training is all about is to teach some of these basic knobs that can be fine-tuned to help people communicate more effectively,” highlights Rijssenbeek. “The first and probably most important knob is active listening. As simple as it may sound, active listening is often completely overlooked and underappreciated.”

According to Rijssenbeek, in the high-tech domain, when surrounded by highly intelligent experts, people often think they’re on the same page and have come to an agreement, only to find later that they interpreted the conversation completely different. “Too often, we fall in the trap of being stuck on send, rather than receive, or truly listening. Active listening takes practice and effort and requires someone to turn off their desire to jump in, to really hear and understand what someone is saying,” explains Rijssenbeek. “The easiest way to do this is to listen intently and then give a summary response to ensure understanding. It might sound easy, and it can be, but that’s one of the most effective parts of the training.”

Another knob used to help promote effective communications is the nonverbal cues, like body language and facial expressions that we use to communicate. “Nonverbal cues can be difficult for technical people to pick up on. With many of them tending to have their focus on content rather than interaction, they often have the expectation that others perceive things the same as they do. Reality, on the other hand, suggests something else,” says Rijssenbeek. “That’s why we spend the vast majority of the training practicing these and other skills. This isn’t a course based on theory and endless discussions, it’s about putting it to practice and trying to build new habits to better navigate communications in a technical workplace.”

This article is written by Collin Arrocho, tech editor of Bits&Chips.