Transparency, T-Shaped Engineers, and FPGAs: Interview with Jami Friedman

Some leaders announce themselves with bravado. Others do it by showing the schematics of what they do not know and building trust from there. Jami Friedman, Executive VP at Leaf Labs, belongs to the second camp.

Leaf Labs is not building consumer apps or headline-chasing AI demos. They operate closer to the metal: firmware, FPGAs, low-level computing. The quiet foundations that make everything else possible. And while Jami does not come from a technical background, she now manages operations, program management, and business development for one of the most technically literate small teams I have encountered.

Her path started with identifying what she didn’t know, and then absorbing like a sponge.

“My approach was to absorb everything by being around it. I’m sure I made a lot of mistakes. But the only way out is through."

Starting Outside the Code

Jami did not cut her teeth debugging embedded Linux or routing DDR traces. She started with people and programs, first at Bose, then Amazon, then PerkinElmer. Her skill was process, not silicon. At first, she thought a program was a program, regardless of domain. Hardware taught her otherwise.

“Once you're locking in your design, you're spending real money. There's a lead time. You're committed.”

That is the hard truth of hardware. Unlike software, you do not push a patch tomorrow. A missed impedance target or a return path that jumps a split plane means weeks of waiting and thousands of dollars burned.

Anyone who has seen a prototype run derailed by a signal integrity mistake knows the pain. A trace crosses a gap, a via forces an ugly loop, and the eye diagram collapses. On paper, the schematic worked. In the lab, it falls apart. These are the mistakes that do not just slow projects. They threaten entire roadmaps.

Jami’s respect for this reality did not come from textbooks. It came from sitting in rooms with engineers, listening for the logic under the acronyms, and making sure momentum did not stall.

FPGA Practice: Timing, Edges, and the Discipline of Traceability

If there’s one domain that exposes the gap between theory and practice in hardware, it’s FPGA design. You can write beautiful RTL, you can simulate endlessly, but if you miss the physical realities of timing, clocks, and resets, the board will remind you who is in charge.

This is why the best FPGA engineers carry equal parts humility and rigor. As Kevin Morris at EE Journal likes to say, FPGAs are “where software habits go to die.” They look programmable, but at their heart they’re hardware. And that distinction matters.

Constraints as the Specification of Physics

The constraint file is not bookkeeping — it is the spec for how physics and logic will negotiate. A thoughtful engineer like Clive Maxfield (“Max,” author of Design Warrior’s Guide to FPGAs) will tell you: constraints are living documents, not static files. Good constraints are explicit. Clocks are named, derived clocks are documented, and false or multicycle paths exist only when proven. Many late-stage bugs have nothing to do with logic errors and everything to do with lazy constraint handling.

Clock Domain Crossings: Respect the Edges

If you want to measure a team’s maturity, watch how they handle clock domain crossing (CDC). Metastability does not care how clean your block diagram looks. Ken Chapman of Xilinx famously called metastability “the silent killer.” The practices are known: two-flip-flop synchronizers for single-bit signals, FIFOs for buses, proper gray coding when counters cross domains. Yet many failures trace back to engineers assuming the tool will “figure it out.” Tools do not prevent physics. The best FPGA designers assume every domain is guilty until proven synchronized.

Resets: A Discipline, Not an Afterthought

Resets might be the most underestimated part of an FPGA design. Choose synchronous or asynchronous based on device and context, but choose deliberately. Reset trees should be designed with the same rigor as clock trees. Watch fanout. Verify exit sequences. Many of the “intermittent” bring-up nightmares in lab notebooks are not random at all — they are the direct result of sloppy reset strategies.

Observability: Design for Debug

Experts like Dan Gisselquist, author of the ZipCPU blog, constantly emphasize the need for observability. Integrated Logic Analyzers (ILAs) are not overhead; they are lifelines. Great FPGA engineers leave hooks, signals, and debug buses woven into the design from the beginning. They accept that no simulation environment captures everything. Observability is how you turn a black box into a transparent system.

Floorplanning and Physical Awareness

A clean floorplan is a kindness to your future self. No, you don’t need to lock every slice, but thoughtful placement — keeping related logic near its pins, grouping timing-critical modules, constraining interfaces — often makes the difference between endless timing closure sessions and a design that just works. Peter Alfke, a long-time Xilinx engineer and one of the legends of FPGA history, used to remind young designers: timing is geometry. Ignore it, and the device will remind you.

Traceability and Reproducibility

Nothing is more frustrating than a bitstream that works once and can never be recreated. Version lock your tools. Record build seeds. Capture exact constraint file versions. If a board in the lab passes bring-up, make the build reproducible. Great teams treat FPGA artifacts the same way they treat source code: immutable, traceable, and reviewable.

The Generalist’s Edge

And here is where Leaf Labs’ ethos intersects FPGA practice. The best FPGA designers are never only FPGA designers. They understand that their constraints live downstream of PCB stackups and upstream of embedded software. If a transceiver lane fails, they check reference planes and return paths, not just the IP core. If jitter shows up, they ask about the oscillator, the PLL, and the power rails.

The names you hear when people talk about quality FPGA craft — Clive Maxfield, Peter Alfke, Ken Chapman, Dan Gisselquist — all share one thing: they approach FPGAs as systems, not just chips. That’s the spirit Leaf Labs tries to embed in every engineer. Breadth makes you better at depth.

People as the Core System

Despite the wall of acronyms at Leaf Labs, Jami spends her energy elsewhere: people.

“If our team isn’t happy, nothing else will go well.”

In a 21 person company, that is not a platitude. There is no buffer. If one engineer is struggling, the project feels it. And because engineers at Leaf Labs wear wide hats, the cognitive load is real. Generalism here is not a buzzword. It is survival.

That requires a culture where it is safe to ask dumb questions, where an electrical engineer can peek into cryptography without embarrassment, and where curiosity is rewarded as much as shipped code.

It is also why Leaf Labs resists scaling to the hundreds. Their work depends on transparency and human connection. Growth for its own sake would fracture both.

Building Multidisciplinary Engineers

Rather than hiring finished unicorns, Leaf Labs grows engineers into broader roles. The filter is not which languages you know. The filter is whether you can trace a system. Can you walk through how data flows? Can you see how one layout choice cascades into firmware constraints?

“We don’t expect people to be experts in everything,” Jami said. “But we do expect that you’ll cross into new domains, at least enough to speak the language.”

This is the logic of T shaped engineers. A deep vertical in one area combined with a broad horizontal across the stack. The shape gives you credibility and adaptability.

At Leaf Labs, hiring for systems thinking means a young engineer with the right mindset might outperform a veteran with narrow expertise. They have seen seasoned professionals stumble in interviews while new grads soar, simply because one group focused on tools while the other focused on systems.

That is why their interviews emphasize mental models. It is also why they take candidates to lunch, not to grill them, but to let them meet the people who will rely on them.

Systems All the Way Down

Jami thinks about organizations the way engineers think about boards. Where are the thin traces. Where is the bottleneck. Where is load unbalanced.

Her lens is process as system. Hardware programs are dependencies and timing constraints. A part order here, a review there, a test jig down the line. Any misalignment, like a bad via on a split plane, ripples across the whole design.

“It’s not so different from business process intelligence,” she said. “But instead of optimizing a supply chain, we’re optimizing digital logic.”

That view makes her leadership about flow. Keep the circuit of people and tasks from breaking under load.

Transparency as Hardware

Leaf Labs does not ship products under its own name. They ship trust for other companies. In those programs, the biggest differentiator is not technical brilliance. It is communication.

The best projects are the ones where communication is constant, even over communicative. Photos of messy benches. Notes about partial progress. A quick screenshot instead of waiting for the final version.

“We want no client to ever wonder what we’re working on,” she said.

This might sound small, but in hardware, where errors hide until fabrication, it is everything. Over communication buys time. It creates options. It is the Agile idea applied to physical systems. Smaller increments, faster visibility, shorter feedback loops.

Hardware will never be as flexible as software, but adopting Agile practices makes it less brittle. Sprint reviews, daily updates, early prototypes. Transparency is the enabler. Without it, Agile turns into a slogan. With it, hardware teams work in development mode rather than production mode and catch errors while they are still cheap.

Structure as a Scaffold

Leaf Labs has no ambition to become a 200 person firm. Not for lack of ambition, but because their structure is intentional. Growth for its own sake dilutes transparency and fractures communication.

“Structure gives us freedom,” Jami said. “It gives us the mental space to be thoughtful.”

Here, structure is not bureaucracy. It is the scaffold that supports creativity. It is the guardrail that lets generalists do broad, risky work without chaos. It prevents engineers from reinventing process or stepping on each other’s toes.

In a large company, structure calcifies. At Leaf Labs, structure is alive. Handoffs are explicit, communication is real time, feedback loops are short. This is not accident. It is engineered.

Leadership in Curiosity

What struck me most was not what Jami knew, but how she approached not knowing. With curiosity. With humor. With openness.

“If I could go back, I’d ask more questions. I wouldn’t brute-force my way through so much.”

In a field where technical authority is often performed like theater, her leadership style is human. She does not hide her learning. She treats the team as a system where emotional load matters as much as timing constraints.

Culture often dictates the success of technology. You can have brilliant engineers, but if they do not feel safe admitting gaps, you will not get the full benefit of their creativity. Curiosity at the top ripples through the system.

A Philosophy for Building Future Hardware

If you strip away the acronyms and the process charts, what remains is a simple question. What kind of world do we build when we ship hardware.

Hardware persists. It takes space, power, and attention. It teaches its users a rhythm. It sets expectations for reliability and repair. It either invites stewardship or it invites waste. Every time a team locks a design, it makes a small bet about how people should live around that object.

That is why humility belongs in the process. Transparency is not only a management technique. It is an ethical stance. It says we will show our work, we will invite critique, and we will design with the future in mind rather than only the launch date.

A philosophy for future hardware might sound like this. Build for clarity. Prefer observability over cleverness. Make choices that reduce hidden coupling. Treat power, timing, and security as first class. Leave room for repair. Document decisions like someone else will inherit them, because someone will. Aim for tools and architectures that let new engineers join the conversation fast. Favor designs that can be reasoned about by a human under pressure.

Most of all, align the culture with the physics. Encourage early visibility. Reward calm problem solving. Give people enough structure to be brave. If we do that, we do more than ship boards. We teach a way of working that outlasts the product.

Lessons for Hardware Rich Development

Talking with Jami clarified a set of truths that are easy to forget in the rush of delivery.

• Transparency is not optional. Silence in hardware costs too much. Share early, even when it is messy.
• Generalism is structural. The most valuable engineers connect domains and think in systems. Depth still matters, but breadth creates resilience.
• Structure is freedom. Good systems give engineers space to think, not the burden of chaos.
• Curiosity is leadership. Admitting you do not know builds more trust than performing certainty.
• Respect the FPGA flow. Constraints, CDC, resets, and traceability will decide your schedule more than any one block of RTL.

In many ways, Leaf Labs embodies Hardware Rich Development. Not because they stack more acronyms, but because they treat hardware as both circuits and culture. Their approach is to engineer systems of people as carefully as they engineer systems of logic.

Maybe that is the broader lesson for any technical leader. Engineering is always systems thinking. The only question is which systems you choose to notice.