Life of a hardware engineer

What does a hardware engineer do?

A conversation with Simon-Thijs de Feber

What does a hardware engineer do all day? It’s a question we get more often than you might expect, partly because FPGA design is a niche discipline and partly because the answer is less straightforward than you might think.

We sat down with Simon-Thijs de Feber, team lead at QBayLogic, to find out.

You’ve been at QBayLogic for a while now. What does your current work look like?

Right now, I’m in a slightly unusual position. We’re preparing a product of our own, which means I’ve been writing a business plan, conducting a feasibility study, building a proof of concept, and putting together a presentation for potential investors. It’s a completely different set of skills compared to my usual engineering work, but it’s part of what makes this job interesting.

Before this, I led a project that ran for just over a year. That was more typical: leading a team of three, managing the day-to-day engineering work, and handling client communication. It involved everything from design and verification to preparing a live demo of the final product.

Your title is “team lead”. What does that mean at QBayLogic?

Not as much as you might think. We don’t do hierarchy here. The way I see it, you do things together. Sometimes I take the lead, sometimes a colleague does. It depends on what’s on the table at that moment. If someone has deeper knowledge of a particular technical area, they lead that part. I’m not standing here looking over anyone’s shoulder telling them what to do. What matters is that the work gets done well and that everyone in the team gets to do what they do best.

How do you typically spend your days?

When I’m on a project, roughly a quarter of my time goes to meetings, planning, and what I’d call peripheral matters: the things that need to happen around the actual engineering to keep a project moving. The other three quarters is design and verification work.

That mix suits me. I like the variation. Some of my colleagues prefer to dive deep into technical details for entire days, working on type definitions, digging into language reference manuals, that kind of thing. And that’s valuable work. They know everything about the tools and programming languages we use, and you need that depth in a team.

But I’m more of a generalist. I like switching between focused technical work and the communication and coordination side of things. It can be challenging, though. Combining meetings with deep focus work requires discipline. When you’re pulled out of a design problem, it takes real effort to get back in.

Who do you typically work with on the client side?

Other engineers, mostly. Sometimes team leads or project managers, but the primary contact is usually technical. Our work is so specialized that the conversations need to be technical. That works best when both sides have engineering backgrounds.

You work at the company that invented Clash, but you don’t use Clash yourself?

That’s right, I’m a bit of the odd one out here. My background is in ASIC and FPGA design using VHDL and Verilog, with industry tools from Cadence and Synopsys. I have a strong preference for GHDL as my simulation tool. I’m planning to learn Clash this year, but so far there have always been other interesting projects where my existing skills were a better fit.

It’s also partly client dependent. Some clients want their project done in a specific language or with specific tools. In the project I led, the client wanted VHDL, and that’s where I’m most at home. When we have a free hand, the team generally reaches for Clash, but there’s no dogma about it.

As a hardware engineer, what are your daily frustrations?

Not very many. The engineering itself is almost always enjoyable, even when it’s difficult. The one thing I don’t like is having to tell a client that a project is running late. That’s a phone call nobody enjoys making.

This happened in the project I led, but we were fortunate: the client was understanding and reasonable about it. And, as always, I had great support from both Christiaan and Maarten within QBayLogic. Management here always backs the engineer. That makes a real difference when you’re having a difficult conversation with a client.

But even when the client takes it well, you still ask yourself the hard questions afterwards. Did we miss a risk we should have caught earlier? Should we have tested something sooner? Is there something in our process we need to improve? We’re always looking for ways to get better, and we really dislike repeating past mistakes.

Sometimes the answer is that the complexity just came with the territory. Long projects with many dependencies and stakeholders will always produce surprises. But you still do the post-mortem and look for lessons to learn.

In your experience, what’s the one thing that derails project planning most?

Design work, you can plan. Verification, same. But the moment you hit a bug, all bets are usually off. You don’t know what’s causing it yet, so you can’t know how long it’ll take to find and fix. That’s just the nature of it.

In our case, the complexity of a piece of existing technology on the client side was underestimated during the original planning phase. That wasn’t anyone’s fault really, but it meant we encountered issues we couldn’t anticipate. Those took time to resolve.

I think anyone who claims they can accurately plan a year-long engineering project is being optimistic. Human beings are not well suited to making estimates that far out. You do your best, you build in margins, and you communicate openly when reality diverges from the plan.

What does a good team look like to you?

I think the team is more than the sum of its parts, and this happens when the collaboration works. At QBayLogic, we have people with very different strengths. What makes it work is that everyone respects what the others bring. The specialist doesn’t look down on the generalist for not knowing every detail, and the generalist doesn’t dismiss the specialist’s deep dives as unnecessary. You need both. And when a team clicks like that, you get outcomes that none of the individuals could have achieved alone.