Formula 1 system architecting – Part 3: Fast to fail

‘System architecting under extreme circumstances’ is how you could describe Guido de Boer’s job at Mapper over the past fourteen years. Part 3 in a series of interviews in which he shares with Bits&Chips his unconventional view on developing systems, in the run-up to his keynote at the Dutch System Architecting Conference on 20 June.

High tech start-ups often find themselves in a predicament. Investors insist on outsourcing, but some things just can’t be outsourced. Once the decision for outsourcing has been made, considerable challenges await. The biggest disaster is the supplier who says “I’ll make that for you” but who won’t keep his promise.

Guido de Boer learned it the hard way. His motto: never choose a supplier who promises to deliver what you ask for. “That should set alarm bells ringing. In today’s manufacturing culture, it’s best to choose the supplier who doesn’t want to deliver what you ask for. Who simply says: ‘No, I won’t do that.’ We actually did that at Mapper. We applied for quotes and if a supplier said ‘You’re completely crazy. I can’t do that within this timeframe and budget’, we went on to talk to the guy. Those who said ‘I can do it’, we ignored. That was a very successful strategy for us.”

So if someone immediately said “yes”, you immediately had doubts?

“If someone said ‘yes’ within two weeks, we’d ask how he was going to manage that. If he didn’t come up with a very good story, but something along the lines of ‘trust us’, that was a red flag. Then we were 100 percent sure it would go wrong.”

Have you ever been caught by surprise?

“Hell yes. I’ve learned by bitter experience what can happen if you accept someone asking for your trust. We met suppliers that said they already had the solution for us. But if we asked them for drawings, data and how often they’d already done it, they refused to hand over that information, saying it was confidential. Later I learned: never mind. I know experienced managers at large semicon equipment builders who feel exactly the same: if suppliers don’t want to show it, it’s just not there.”

But if a supplier says: “This is too difficult. We can’t do that within the requested time?”

“Then you start asking: why not? And then they come up with a list of problems that will make you very happy. Because, in fact, you’re experiencing the first verification test. With complex systems, it’s all about being fast to fail. It’s all about making a lot of mistakes very quickly. It’s a loop: you very quickly put a concept on paper, have it tested, derive requirements from it and ask people if they can meet those requirements. If that’s not possible, you ask them what is possible. And then you walk the same path again.”

De Boer realizes that his view of the relationship with suppliers might sound cynical. “But what applies to suppliers also applies to engineers in relation to their project leader. The ambitious young engineer is happy to proclaim that he can solve the problem and the ambitious young project manager is happy to hear that message. This pattern is repeated everywhere in the world. I honestly don’t know how to break it. In any case, you should always plan for failure. That’s why I find Agile and the fast-to-fail philosophy in systems engineering so interesting.”

Risky R&D

Start-ups and mature OEMs face substantially different challenges. Their outsourcing and purchasing strategy differ. Well-established high tech players pay attention to issues such as margin increases, cost control and new product generations in make-or-buy decisions. They often choose to develop core technology in-house. They purchase everything that’s non-core as standard parts or have it made by suppliers.

To starters, that classical wisdom is of little use. According to De Boer, they need to concentrate on the essence, on how to take the next step. This leads to other priorities in outsourcing, engineering and R&D. “You have to optimize all resources for your chances of survival,” he explains. “Start-ups only have to look one investment step ahead, pull out all the stops to make the next investment round.”

The first question they have to ask themselves is: do I have requirements for which I have to push boundaries? Are they very different from what the rest of the world wants? Mapper had to prove that it could do lithography with thousands of parallel electron bundles. “So we really had to push the limits,” says De Boer. “We needed a data path of 14 terabytes per second of information for that. That’s quite disruptive. With that information, we had to control a blanker chip on the fly, switching 650 thousand electron beams ‘on’ or ‘off’ individually. We put a great deal of effort into this.”

Mapper’s initial focus on electron sources shows how difficult it is to set priorities and to see what impact a choice can have. To generate electrons for 650,000 electron lenses, the source had to be able to handle much higher currents than commercially available sources could. That’s why Mapper initially considered this technology to be of strategic importance. “We wanted a high throughput and needed a source of 100 milliamps. That’s a lot for an electron source.”

The start-up even bought IP from Philips to achieve higher brightness. “That turned out not to work. We threw away two man-years before we realized that we could also do it with sub-bundles. The latter came down to engineering, not research. Moreover, this was in line with our strategy to minimize risky R&D.”

De Boer’s conclusion now is that Mapper put too much effort into electron sources in the beginning. “In retrospect, it wasn’t necessary nor wise to develop new source technology. We could have bought a more standard source to begin with and we would have been set until 2015. You can argue that we would have missed out on strategic knowledge, but perhaps we would have paid more attention to the blanker.” More about this project, that would eventually break Mapper’s neck, in part 4 of this series.

It remains a difficult choice whether to make small steps on many fronts or achieve greater results on fewer fronts. In addition to keeping focus, the question is always whether you should do something essentially new, something that really can’t be done with existing technology. “Only bitter necessity can seize your resources. If existing technology is a factor of two less optimal, there’s no bitter necessity.”

It’s a subject that De Boer will delve into extensively at the Dutch System Architecting Conference on 20 June: start-ups are working on disruptive developments but they still have to consider when to deliver specific requirements. “At Mapper, we made the mistake of paying far too much attention to the electron source in the beginning, while commercially available sources were good enough for us in the initial phase. We’ve learned that you have to look very carefully at which requirements are critical for your next milestone, your next investment round. There may be disruptive requirements, but you may not necessarily have to solve them all to reach your next milestone. It might be a better idea to buy first and solve problems later.”

Brute engineering

Another brain teaser was the wafer stage. Mapper had Schneeberger develop and make that, but in retrospect, there was an easier way to do it. The driving force behind the development was the avoidance of magnetic fields that could disturb the electron beams. Schneeberger, therefore, chose ball bearings with titanium instead of iron. “E-beam machines with ball bearings are nothing new,” says De Boer. “In the end, we used a fairly standard linear motor, the magnetic field of which we shielded well.”

Looking back, De Boer sees an even easier way. “With what I know now, I would simply ignore that magnetic field requirement. What can go wrong? Last week, just for fun, I designed a system in which a linear motor – one with magnets – moved a stage under an SEM. That’s perfectly possible, although you need to be a little creative.”

Ruminating: “Young engineers want to solve every problem. When you get older, you tend to say: what if I don’t solve everything? What happens then? What if I just grab a standard linear motor for the wafer stage and place it a little further away? That’s much more the way I think and act now. Just ignoring risks in a balanced way and looking at what might go wrong.”

You know that problems arise, but you ignore them for the time being?

“Yes. And if the problem already exists, just leave it unsolved for a while. For the first milestone, you simply accept that. You’ll have more time later and solve it then. I really think we made a mistake by trying to build a very beautiful machine first time right. That’s wonderful, and it has also been successful in terms of architecture, but it has taken us too long, so I would never do it again the same way.”

With all these crucial choices, an orchestra of advisors always plays in the background. “That’s fascinating. I got a lot of people who said: that wafer stage, that’s a very difficult project! It took ASML 25 years to do it. Nanometer accuracy, vacuum compatible, magnetic fields: all very difficult! At a certain point, I knew it could work with a combination of more or less standard components. People had a fast, ASML-like stage in mind, but we only had to move at ten millimeters per second. The vacuum requirements weren’t as high either.”

In general, De Boer says, you can best solve problems with brute engineering. “ASML does that too. Suppose you want to design an airplane wing and you find out that there’s no means of transporting it. Engineers then tend to design a special truck for it. But in such a case, it’s better to buy ten vans, place a plate on top, call the police and drive that wing to a boat at night. I mean: do something, but whatever you do, don’t develop that truck.”

This concludes part 3. Parts 1 and 2 were published two weeks ago and last week, respectively. Stay tuned for part 4 next week. Visit the Dutch System Architecting Conference on 20 June to hear Guido de Boer’s full story on how to apply systematicness and regularity when prioritizing R&D in a start-up and in choosing when to outsource or to purchase.