As Nearfield Instruments scales from startup to established player in atomic force microscopy-based metrology, systems engineering has become mission-critical. Through a tailored training program with TNO-ESI, the company is embedding architectural thinking across the organization – and solidifying that good systems engineering starts with the end in mind.
“We’re a young company,” says Frank Pasveer, director of systems engineering at Rotterdam-based Nearfield Instruments. “We already had several standards in place and we used the V-model, but every time new people joined, they brought different habits and terminology from previous employers. We required a unified way of architecting.”
Pasveer himself joined Nearfield in January of 2025 and immediately noticed the challenge. “Among the first topics I discussed with my team were systems engineering, systems architecting and the need for a potential training,” he notes. “That process – to do architecting in a uniform way across the company – wasn’t really there. So, we decided to train everyone together so that we all start speaking the same language and working in the same way. We wanted to create common ground both for our existing employees and for future new hires.”
Instead of shopping off the shelf, Pasveer contacted TNO-ESI’s program manager for systems engineering, Joris van den Aker, an old acquaintance from his Philips days, to explore a bespoke approach. “Why look for a generic training with little room for tailoring?” Pasveer recalls. “Why can’t we put together a dedicated course? Joris and I spent an afternoon looking at what’s important for Nearfield, which topics matter and from that, we created a tailored program.”
The program ran over several months in 2025, with two days in April, three more days in May and final presentations in September. Close to twenty participants joined from across the organization – not just the 12-15 people in systems engineering (SE), but also architects from the development and engineering teams (D&E) and senior engineers from R&D who showed potential to grow into architecting roles. The goal was to create “a capability – not just individual skills, but that teams inside the company jointly start architecting,” explains TNO-ESI veteran Gerrit Muller, who led the training program at Nearfield.
Firefighting
The challenge is all too familiar to anyone who has watched a startup mature. “It’s a juggling act,” observes Muller. “On the one hand, you need to remain very market responsive. You don’t yet know exactly what your customers want. You still have to move with those customers and discover where their needs and requirements are. At the same time, you must begin modularizing, standardizing and streamlining manufacturing, installation and maintenance for larger volumes – investments that could reduce flexibility if made prematurely.”
Pasveer describes the challenging reality at Nearfield, which had already grown to more than 230 people when he arrived and was heading toward 400 by the end of last year. “In a small company, one moment you’re tuning a demo machine until late at night so that a performance demonstration works; the next morning, you’re thinking about how to build ten identical units efficiently. As you scale, those ‘hero roles’ become risky.”
The risk, as Muller puts it, is that systems engineers drift into firefighting instead of architecting. “In smaller companies, ‘square-shaped people’ – who are both broad and deep – are very scarce. If you’re not careful, they get sucked into every detail everywhere,” he warns. “This can be necessary and valuable in the beginning, but if you stay in firefighting mode, scaling becomes a disaster.”
To avoid this trap, Nearfield had already transitioned to module ownership inside its D&E organization, which encompasses roughly sixty people. “Earlier, when we were smaller, SE did practically everything, because that’s where the knowledge was,” Pasveer explains. “Now, as the modules become too large for a single systems engineer to manage directly, we want a D&E lead per module who oversees a multidisciplinary team of engineers.” Systems engineering defines system-level requirements and provides direction, but detailed engineering responsibility moves to module architects.
Saying no
Implementing this transition, however, requires careful attention to responsibilities, interfaces and communication patterns. “In large companies, everything is siloed, and communication across silos is already a big challenge,” Muller knows from more than 25 years of teaching systems architecting in high tech. “Luckily, Nearfield is still small enough that people know each other and communicate directly.”
The training program helped sharpen the distinction between technical and project leadership. “We discussed the difference: What’s the role of the systems engineer and the project leader?” Pasveer notes. In a rapidly growing company, this boundary can blur dangerously and systems engineers can easily become overloaded as people start throwing everything onto their plates. Muller: “Part of the training is helping them learn to say no, keep technical ownership and avoid sliding into the role of a project manager or a pure requirements engineer.”
An important learning for Pasveer was that the interface between systems engineering and product marketing wasn’t tight enough. “The first evening, as I walked into the training room with all the flip charts and Post-its, I started reading through everything,” he recalls. “And I saw comments written by the teams, like ‘missing marketing knowledge’ and ‘better interaction required.’ So, clearly, we weren’t working as closely with product marketing as needed.”
That’s being actively addressed, Pasveer points out. “For a new development, SE and marketing sit together to create a product requirement specification: What’s the application? What exactly is needed? Is it feasible? Instead of just saying ‘we need this for this application,’ we now dive into real details, discussing things like the criticalities of gate-all-around and what measurements we might enable for such transistor structures.”
Customer value
Central to Nearfield’s systems engineering efforts is “end-to-end ownership” – a principle that Pasveer summarizes succinctly: “Start with the goal in mind. Whatever you need to do to deliver the right outcome, you do it. We see a key role for architects there.” Muller elaborates on this architectural thinking: “That ‘end’ is the system operating at the customer’s site. If there’s an issue there, for example with reliability, you reason all the way back and ensure that your design is correct.”
The pre-existing internal emphasis on customer value was one of the things that very positively surprised Muller during the training. “Usually, I’m the one pushing people to think from customer value, but at Nearfield, the CEO was even more demanding than I was.” The principle lies at the heart of his company’s philosophy, acknowledges Pasveer. “If you truly understand the customer’s problem, you don’t just solve the immediate issue; you can see the broader problem and design a more future-proof solution. That’s where architecting already comes into play: thinking about scalability, future steps and long-term relevance.”
As part of the training, five multidisciplinary groups tackled real, customer-facing challenges. One team focused on commissioning and diagnostics, working on cycle-time reduction through software and scripting. “Diagnostics is often undervalued compared to core technology development, but for scaling, it’s absolutely crucial,” Muller points to a major realization during the program. Pasveer agrees: “We’ve learned that for scaling, diagnostics must be fast and reliable. Our internal requirement is: 90 percent of cases must be diagnosable within half an hour. Otherwise, scaling is impossible.”
Other teams addressed new product developments in the training, like scanning larger surface areas and next-generation measurement head architectures. “I didn’t want toy projects,” Pasveer emphasizes. “The participants had to experience immediate value – not just learning a trick, but really applying it to projects and reality. After the first part of the program, we even switched some of the team topics to make them more directly applicable.”
Leadership and ownership
Equally directly applicable is the A3 deliverable. This concise, visual document capturing context, customer value, requirements, architectural decisions, constraints, risks and validation thinking was a pivotal mechanism in the training. “We insisted that every team produce multiple A3s and present them to senior stakeholders,” TNO-ESI’s Van den Aker notes. “A3s force consistency and discussion. They create a powerful communication tool across the organization.”
For Pasveer, it has become a living standard at Nearfield: “Every new project starts with an A3. The teams adopted this during the training program, and it’s now fully embedded.” Muller adds: “Large companies can write large documents; we push the opposite: concise overviews, many if needed, but always focused and communicative.”
The effect goes beyond documentation. “Architecting is not only about content, but it’s also about leadership and ownership,” Van den Aker explains. “When people create A3s and discuss them, they naturally develop more leadership and ownership.”
Pasveer agrees. “Creating an A3 stimulates ownership. People have laid the first piece of the puzzle and they like to see it finished. As they invest time, they come to believe in it, so they want to take it all the way and naturally start pushing for realization.”
Iteration at every level
Likewise, Nearfield is absorbing the other learnings from the training program. It’s extending its V-model approach with Muller’s CAFCR framework, which looks at a system from five different angles: the customer objectives, the application, the functional view, the conceptual view and the realization. Pasveer: “In new projects, we’re following the recipe step by step, in an iterative process.”
“Right,” interjects Muller. “The V-model isn’t a waterfall process. People often confuse the two. With the V-model, you’re constantly thinking ahead. Every requirement must be connected to validation and implementation considerations. Do I really understand the customer’s goal? Can I actually implement it? What are the consequences?” Pasveer concurs: “You don’t just toss something over the fence. There’s iteration at every level of the V.”
Muller also introduced the systems engineers at Nearfield to the concept of time-bound problem-solving. “In our weekly SE meetings, we now regularly spend 15-30 minutes brainstorming about open issues,” elaborates Pasveer. “Very pragmatic, but it’s really paying off already.”
New energy
Meanwhile, the relationship between Nearfield and TNO-ESI continues to evolve. “Embedding these ways of working into the DNA of the company takes time,” Van den Aker notes. “So I’m sure that a year from now, Frank and I will sit down again for coffee and ask: How far has it embedded and where’s the next level?” With Nearfield’s continuing growth, new training cohorts seem inevitable, but Van den Aker stresses that the company first needs time to digest what it has learned.
Architecting maturity is never static, adds Muller. “The principles are generic, but how you apply them must evolve with company size and accumulated experience. My rule of thumb: Every growth factor of square-root-two requires a new way of working. As you grow, you must continuously adapt how you collaborate and architect. Knowledge dilutes, teams no longer fit in one room, coordination changes, onboarding becomes harder – many dynamics shift.”
From the collaboration with Nearfield, Muller has learned a lot about AFM technology and its business potential in semiconductor volume production applications. “In retrospect, we should have focused earlier in the training on the business modeling. This is something we’re taking into account for future trainings with startups and scale-ups”.
Pasveer especially hopes to maintain the new energy the training program has infused into Nearfield’s systems engineering. “I see a lot of engagement and enthusiasm to put the learnings into practice. In meetings, people are proactively asking for A3s and assuming one of the CAFCR viewpoints. The training has brought a fresh, positive vibe.”
This article was written in close collaboration with TNO-ESI.
