‘System architecting under extreme circumstances’ is how you could describe Guido de Boer’s job at Mapper over the past fourteen years. The fourth and final part 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.
Looking back on his first introduction to Mapper Lithography in 2004, Guido de Boer sees a lot of ambition, but little foundation. He boarded a club of academics without any machine development experience and with little money. De Boer knew that he was going to manage a project of a formidable size. He was particularly concerned about the lack of realism and the lack of structure in the machine that had to be built.
But the start-up was still small and malleable at that time. “I could start with a clean sheet. Remco Jager also had very clear ideas. We worked out and shaped everything together.”
De Boer fought against the natural tendency of people and organizations to compartmentalize. “As a matter of course, silos are created at a breakneck pace within every company. People start tangling: software, electronics, but also purchasing, human resources and sales. The mono-disciplines gather, define a working method and start to optimize their work. From the person that manages the parking lot to the technicians developing the electron source – people organize themselves around their little trick.”
De Boer considered it his mission to break this pattern at Mapper. The company founders, Marco Wieland and Bert-Jan Kampherbeek, supported him. “At Mapper, we had no software department, no mechanics department. Never had. No groups.”
Device lifecycle management for fleets of IoT devices
Microchip gives insight on device management, what exactly is it, how to implement it and how to roll over the device management during the roll out phase when the products are in the field. Read more. .
Are groups not good?
“Birds of a feather flock together. It’s human nature. We want to be with peers. Take taxi drivers. When I leave an airport, they’re talking to each other instead of approaching potential customers. Software developers like to talk to software developers, mechanics like to talk to mechanics. It crystallizes very quickly. Before you know it, another group has emerged that can do whatever trick.”
How did you obtain this knowledge?
“From books like The Innovators Dilemma, Crossing the Chasm, The Weakest Link. I read a lot of stuff like this during a shortened MBA at the Rotterdam School of Management while working at ASML. You get to see a common denominator. The silo behavior has been described by many.”
“A good example is the company restaurant for which you need lunch tickets. These lunch vouchers are, of course, handed out at the reception but the receptionist also needs to go to lunch. So you can guess when you can’t buy lunch coupons: around lunch.”
“It happens all the time. People optimize their own work. It’s totally fine for each mechanical engineer to have his favorite screws and his favorite 3D design tool. But when a project manager asks him for a different screw designed with a different tool and he says no, then you know your company has turned into silos.”
Technicians also tend to compartmentalize. “For higher educated people, achieving clear goals and mastering their job are among the major motivators. They want to be good at their work, preferably better than their peers. It’s a very basic and profound wish. You see that with women who sew quilts and men who build model trains. If technicians are asked to do something that they don’t know, it feels unpleasant to them. So they ask the project manager if they can do the trick their own way. The project leader requires a laser interferometer but his designer proposes to deliver an encoder because he has already built it twice. If you ask a carpenter to make a car, you can guess what it will look like.”
At Mapper, they decided at an early stage that they didn’t want this. “Because those silos cost a lot of resources. You get bureaucratic discussions about work hours and the toilet paper. Or about which operating system to use. People want to agree based on their field of expertise. But it’s totally irrelevant.”
As a start-up, you just have to survive, says De Boer. “It’s not about the most optimal path, it’s about survival. You have to reach the next investment round. By definition, there’s little money, time and management focus. Everything is dedicated to the next investment. Then you add a step: more money and more customers. It’s not a game of having the best or most efficient software development method. It’s not about reuse of commonality. That’s all uninteresting. It’s about that next money box. More resources mean you can develop faster and you can reach your customers faster.”
Hindsight is 20/20
Mapper’s development organization, with teams that were assembled around modules, proved itself during machine integration. “It was precisely that phase that went very smoothly. The assembly of modules with the associated tests is usually a pain in the ass,” says De Boer. “For years, everyone built modules without anything tangible on the floor. For years, everything is only on lab tables and in boxes. Then, suddenly, all those things come together and it just seems to work. People really thought that was incredible.”
For Mapper’s first e-beam machine, the integration of tested modules into a working whole took only a few weeks. “It didn’t all work perfectly right away, but at least we had no hassle with software escalations, crashing wafer stages or hampering system interactions,” De Boer clarifies. “There were problems, but those were real problems due to the interaction of electrons with the blanker chip. Not problems due to wrong interfaces. That caused a turning point for our shareholders, but also for our colleagues.”
The machine worked, although the lifespan of the blanker chip continued to be a bottleneck. De Boer says that Mapper collapsed with a working machine. “Really very frustrating. The lithographic instrument stitched patterns together with an error smaller than 10 nanometers.”
Laurent Pain from Mapper’s lead customer Leti in Grenoble presented the results at the SPIE conference last February – a few months after the bankruptcy. Pain showed that the machine was relatively easy to upgrade and service thanks to its modularity. “If you need to be inside an e-beam system, you have to clean it and pump it off again. In 2017, we put a totally new blanker in the machine, went through tests and were able to expose a day later. At the end of the day, the blanker chip went on a transport to Leti in Grenoble, the next morning they put it in the machine, the next evening they had exposures and 16 hours later we saw the SEM results. No crazy things happened. We were in control and that was really nice.”
Do you think that start-ups that are involved in this kind of complex system development should always go crazy?
“My daughter burned her hand seriously when she was three. We told her a hundred times that the heating was hot, but she still burned her hand.”
The development of the blanker chip eventually resulted in a few years of delay and ultimately caused the death of Mapper. “We underestimated this,” says De Boer. The blanker is a chip that can deflect thousands of electron beams individually at very high speed. Mapper chose Catena for the design and TSMC for the production. Both partners were important. Catena as a co-investor and TSMC as a potential customer. Ultimately, the advanced IC technology proved to be too vulnerable to the deflecting bundles. They damaged the structures on the chips.”
According to De Boer, this was so critical that Mapper might have had to do several projects in parallel. “We could also have said: we will omit a number of requirements in the beginning. Go slightly slower with slightly larger chips. Then we would also have had a discussion with our shareholders. After all, we had to do ten wafers per hour. But yes, hindsight is 20/20.”
In order to bring the entire project to a successful conclusion and to develop a blanker that would perform satisfactorily, Mapper in 2018 looked for 80-100 million euros of additional funding. In the end, no investor wanted to sign off for that amount.
Why was that amount so high?
“Of the 80 million, half went to the development of the blanker. The rest we needed to keep the existing organization and infrastructure afloat. That’s really annoying. Your cleanroom is running and you also have to maintain the teams that aren’t working on the blanker. That really consumes money.”
De Boer makes it clear that Mapper is a valuable research case and that he would like to place his experiences in a scientific context. He’s currently discussing this with the High Tech Systems Center in Eindhoven. “At Mapper, we’ve carried out risk analyses every year. Every year, we took a snapshot containing our hypotheses and our assessment of the requirements, risks and whether we deemed specific developments necessary to achieve the next milestone. So you can test methods and hypotheses retroactively.”
This concludes the series. Parts 1, 2 and 3 were published over the last few weeks. 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.