Transparenz, T-förmige Ingenieure und FPGAs: Interview mit Jami Friedman

Manche Führungskräfte treten mit großem Getöse auf. Andere zeigen zunächst den Schaltplan dessen, was sie nicht wissen, und bauen darauf Vertrauen auf. Jami Friedman, Executive VP bei Leaf Labs, gehört zur zweiten Gruppe.

Leaf Labs entwickelt weder Verbraucher-Apps noch KI-Demos für Schlagzeilen. Das Team arbeitet näher an der Hardware: Firmware, FPGAs, hardwarenahe Datenverarbeitung. Die stillen Grundlagen, die alles andere ermöglichen. Obwohl Jami keinen technischen Hintergrund hat, leitet sie heute Betrieb, Programmmanagement und Geschäftsentwicklung eines der technisch versiertesten kleinen Teams, denen ich begegnet bin.

Ihr Weg begann damit, die eigenen Wissenslücken zu erkennen und anschließend alles wie ein Schwamm aufzusaugen.

„Mein Ansatz war, alles aufzunehmen, indem ich dabei war. Ich habe sicher viele Fehler gemacht. Aber der einzige Weg hinaus führt hindurch.“

Der Einstieg außerhalb des Codes

Jami sammelte ihre ersten Erfahrungen nicht beim Debuggen von Embedded Linux oder beim Routing von DDR-Leiterbahnen. Sie begann mit Menschen und Programmen, zuerst bei Bose, dann bei Amazon und anschließend bei PerkinElmer. Ihre Stärke waren Prozesse, nicht Silizium. Anfangs dachte sie, ein Programm sei unabhängig vom Fachgebiet ein Programm. Hardware lehrte sie etwas anderes.

„Sobald Sie Ihr Design festschreiben, geben Sie echtes Geld aus. Es gibt Vorlaufzeiten. Sie haben sich festgelegt.“

Das ist die harte Wahrheit der Hardware. Anders als bei Software können Sie morgen nicht einfach einen Patch ausliefern. Ein verfehltes Impedanzziel oder ein Rückstrompfad über eine geteilte Referenzfläche bedeuten wochenlanges Warten und Tausende verlorene Dollar.

Wer erlebt hat, wie ein Signalintegritätsfehler einen Prototypenlauf scheitern lässt, kennt den Schmerz. Eine Leiterbahn überquert einen Spalt, ein Via erzwingt eine ungünstige Schleife, und das Augendiagramm bricht zusammen. Auf dem Papier funktionierte der Schaltplan. Im Labor versagt er. Solche Fehler bremsen nicht bloß Projekte. Sie gefährden ganze Roadmaps.

Jamis Respekt vor dieser Realität stammt nicht aus Lehrbüchern. Er entstand in Besprechungsräumen mit Ingenieuren, beim Zuhören auf die Logik hinter den Abkürzungen und beim Bemühen, den Fortschritt aufrechtzuerhalten.

FPGA-Praxis: Timing, Flanken und die Disziplin der Rückverfolgbarkeit

Wenn ein Bereich die Lücke zwischen Theorie und Praxis in der Hardware offenlegt, dann ist es das FPGA-Design. Sie können eleganten RTL-Code schreiben und endlos simulieren. Wenn Sie jedoch die physikalischen Realitäten von Timing, Takten und Resets übersehen, erinnert die Platine Sie daran, wer das Sagen hat.

Deshalb verbinden die besten FPGA-Ingenieure Demut und Gründlichkeit zu gleichen Teilen. Wie Kevin Morris vom EE Journal gern sagt, sind FPGAs der Ort, „an dem Softwaregewohnheiten sterben“. Sie wirken programmierbar, sind im Kern aber Hardware. Und dieser Unterschied zählt.

Constraints als Spezifikation der Physik

Die Constraint-Datei ist keine Buchhaltung. Sie legt fest, wie Physik und Logik miteinander auskommen sollen. Ein umsichtiger Ingenieur wie Clive Maxfield („Max“, Autor von Design Warrior’s Guide to FPGAs) wird Ihnen sagen: Constraints sind lebendige Dokumente, keine statischen Dateien. Gute Constraints sind explizit. Takte sind benannt, abgeleitete Takte dokumentiert, und False Paths oder Multicycle Paths gibt es nur mit Nachweis. Viele spät auftretende Fehler haben nichts mit Logikfehlern und alles mit nachlässigem Umgang mit Constraints zu tun.

Taktdomänenübergänge: Respektieren Sie die Flanken

Wenn Sie die Reife eines Teams beurteilen wollen, beobachten Sie seinen Umgang mit Clock Domain Crossing (CDC). Metastabilität interessiert sich nicht dafür, wie sauber Ihr Blockdiagramm aussieht. Ken Chapman von Xilinx bezeichnete sie bekanntlich als „lautlosen Killer“. Die Verfahren sind bekannt: Synchronisierer aus zwei Flipflops für Einzelsignale, FIFOs für Busse, korrekte Gray-Codierung bei Zählern über Domänengrenzen. Dennoch gehen viele Ausfälle auf die Annahme zurück, das Werkzeug werde es „schon richten“. Werkzeuge setzen die Physik nicht außer Kraft. Die besten FPGA-Designer behandeln jede Domäne als verdächtig, bis ihre Synchronisierung nachgewiesen ist.

Resets: eine Disziplin, kein Nachgedanke

Resets sind womöglich der am meisten unterschätzte Teil eines FPGA-Designs. Wählen Sie je nach Baustein und Kontext synchron oder asynchron, aber entscheiden Sie bewusst. Resetbäume verdienen dieselbe Sorgfalt wie Taktbäume. Achten Sie auf den Fanout. Prüfen Sie die Sequenzen beim Verlassen des Resets. Viele vermeintlich sporadischen Albträume bei der Inbetriebnahme sind keineswegs zufällig, sondern die unmittelbare Folge nachlässiger Resetstrategien.

Beobachtbarkeit: Debugging von Anfang an einplanen

Experten wie Dan Gisselquist, Autor des ZipCPU-Blogs, betonen immer wieder die Notwendigkeit der Beobachtbarkeit. Integrierte Logikanalysatoren (ILAs) sind kein unnötiger Aufwand, sondern Lebensadern. Gute FPGA-Ingenieure integrieren von Beginn an Zugriffspunkte, Signale und Debug-Busse in ihr Design. Sie akzeptieren, dass keine Simulationsumgebung alles erfasst. Beobachtbarkeit verwandelt eine Blackbox in ein transparentes System.

Floorplanning und physikalisches Verständnis

Ein sauberer Floorplan ist ein Geschenk an Ihr zukünftiges Ich. Nein, Sie müssen nicht jeden Slice festlegen. Doch eine durchdachte Platzierung – zusammengehörige Logik nahe ihren Pins, gruppierte zeitkritische Module, definierte Schnittstellen – entscheidet oft zwischen endlosen Timing-Closure-Sitzungen und einem Design, das einfach funktioniert. Peter Alfke, langjähriger Xilinx-Ingenieur und eine Legende der FPGA-Geschichte, erinnerte junge Designer gern daran: Timing ist Geometrie. Ignoriert man das, erinnert einen der Baustein daran.

Rückverfolgbarkeit und Reproduzierbarkeit

Nichts ist frustrierender als ein Bitstream, der einmal funktioniert und sich nie wieder erzeugen lässt. Fixieren Sie die Versionen Ihrer Werkzeuge. Dokumentieren Sie Build-Seeds. Halten Sie die genauen Versionen der Constraint-Dateien fest. Wenn eine Platine im Labor die Inbetriebnahme besteht, machen Sie den Build reproduzierbar. Gute Teams behandeln FPGA-Artefakte wie Quellcode: unveränderlich, rückverfolgbar und überprüfbar.

Der Vorteil der Generalisten

Hier treffen die Haltung von Leaf Labs und die FPGA-Praxis aufeinander. Die besten FPGA-Designer sind nie ausschließlich FPGA-Designer. Sie wissen, dass ihre Constraints den PCB-Lagenaufbau voraussetzen und wiederum die Embedded-Software beeinflussen. Fällt eine Transceiver-Lane aus, prüfen sie Referenzflächen und Rückstrompfade, nicht nur den IP-Core. Tritt Jitter auf, fragen sie nach Oszillator, PLL und Versorgungsschienen.

Die Namen, die bei hochwertigem FPGA-Handwerk fallen – Clive Maxfield, Peter Alfke, Ken Chapman, Dan Gisselquist –, haben eines gemeinsam: Sie betrachten FPGAs als Systeme, nicht bloß als Chips. Diesen Geist will Leaf Labs jedem Ingenieur vermitteln. Breite macht Sie auch in der Tiefe besser.

Menschen als zentrales System

Trotz der Wand aus Abkürzungen bei Leaf Labs richtet Jami ihre Energie auf etwas anderes: Menschen.

„Wenn unser Team nicht zufrieden ist, wird auch sonst nichts gut laufen.“

In einem Unternehmen mit 21 Mitarbeitenden ist das keine Floskel. Es gibt keinen Puffer. Wenn ein Ingenieur Schwierigkeiten hat, spürt es das Projekt. Da die Ingenieure bei Leaf Labs breite Rollen übernehmen, ist die geistige Belastung real. Generalismus ist hier kein Schlagwort. Er ist überlebenswichtig.

Das erfordert eine Kultur, in der man gefahrlos vermeintlich dumme Fragen stellen kann, in der ein Elektroingenieur sich ohne Scham mit Kryptografie beschäftigen darf und Neugier ebenso belohnt wird wie ausgelieferter Code.

Deshalb will Leaf Labs auch nicht auf Hunderte Mitarbeitende wachsen. Die Arbeit hängt von Transparenz und menschlichen Verbindungen ab. Wachstum um seiner selbst willen würde beides beschädigen.

Ingenieure mit mehreren Disziplinen entwickeln

Statt fertige Alleskönner einzustellen, entwickelt Leaf Labs Ingenieure in breitere Rollen hinein. Entscheidend ist nicht, welche Programmiersprachen Sie kennen. Entscheidend ist, ob Sie ein System nachvollziehen können. Können Sie den Datenfluss erklären? Erkennen Sie, wie eine Layoutentscheidung Anforderungen an die Firmware nach sich zieht?

„Wir erwarten nicht, dass alle in allem Experten sind“, sagte Jami. „Aber wir erwarten, dass Sie in neue Gebiete vordringen, zumindest so weit, dass Sie deren Sprache sprechen.“

Das ist die Logik T-förmiger Ingenieure: eine tiefe Vertikale in einem Gebiet, kombiniert mit einer breiten Horizontalen durch das gesamte System. Diese Form schafft Glaubwürdigkeit und Anpassungsfähigkeit.

Wer bei Leaf Labs nach Systemdenken einstellt, weiß: Ein junger Ingenieur mit der richtigen Haltung kann einen erfahrenen Spezialisten übertreffen. Das Team hat erlebt, wie erfahrene Fachkräfte in Interviews stolperten, während frisch Graduierte glänzten – schlicht weil die einen auf Werkzeuge und die anderen auf Systeme blickten.

Deshalb stehen in ihren Interviews Denkmodelle im Mittelpunkt. Deshalb gehen sie auch mit Bewerbern essen: nicht um sie auszufragen, sondern damit sie die Menschen kennenlernen, die sich auf sie verlassen werden.

Systeme auf jeder Ebene

Jami betrachtet Organisationen so, wie Ingenieure Platinen betrachten. Wo sind die dünnen Leiterbahnen? Wo ist der Engpass? Wo ist die Last ungleich verteilt?

Sie sieht Prozesse als Systeme. Hardwareprojekte bestehen aus Abhängigkeiten und zeitlichen Vorgaben. Hier eine Teilebestellung, dort ein Review, später eine Testvorrichtung. Jede Fehlanpassung wirkt wie ein ungünstiges Via an einer geteilten Referenzfläche durch das gesamte Design.

„Das unterscheidet sich nicht so sehr von Business Process Intelligence“, sagte sie. „Aber statt einer Lieferkette optimieren wir digitale Logik.“

Mit diesem Blick wird Führung zur Arbeit am Fluss: Der Kreislauf aus Menschen und Aufgaben darf unter Last nicht reißen.

Transparenz als Hardware

Leaf Labs liefert keine Produkte unter eigenem Namen aus. Es liefert anderen Unternehmen Vertrauen. In diesen Projekten ist der größte Unterschied nicht technische Brillanz, sondern Kommunikation.

Die besten Projekte kommunizieren ständig, sogar über das übliche Maß hinaus. Fotos unordentlicher Werkbänke. Notizen über Teilerfolge. Ein schneller Screenshot, statt auf die endgültige Version zu warten.

„Kein Kunde soll sich je fragen müssen, woran wir arbeiten“, sagte sie.

Das mag unbedeutend klingen. Doch in der Hardware, wo sich Fehler bis zur Fertigung verbergen, ist es entscheidend. Häufige Kommunikation verschafft Zeit. Sie schafft Optionen. Das ist der agile Gedanke, auf physische Systeme übertragen: kleinere Schritte, schnellere Sichtbarkeit, kürzere Rückkopplungsschleifen.

Hardware wird nie so flexibel sein wie Software, doch agile Praktiken machen sie weniger starr. Sprintreviews, tägliche Updates, frühe Prototypen. Transparenz ermöglicht das. Ohne sie wird Agilität zur Parole. Mit ihr arbeiten Hardwareteams im Entwicklungs- statt im Produktionsmodus und erkennen Fehler, solange diese noch wenig kosten.

Struktur als Gerüst

Leaf Labs strebt keine Firma mit 200 Mitarbeitenden an. Nicht aus mangelndem Ehrgeiz, sondern weil die Struktur bewusst gewählt ist. Wachstum um seiner selbst willen verwässert Transparenz und beschädigt Kommunikation.

„Struktur gibt uns Freiheit“, sagte Jami. „Sie schafft den geistigen Raum, um umsichtig zu sein.“

Struktur ist hier keine Bürokratie. Sie ist das Gerüst für Kreativität. Sie ist die Leitplanke, dank der Generalisten breit und risikoreich arbeiten können, ohne im Chaos zu enden. Sie verhindert, dass Ingenieure Prozesse ständig neu erfinden oder einander in die Quere kommen.

In großen Unternehmen verknöchert Struktur. Bei Leaf Labs lebt sie. Übergaben sind klar definiert, Kommunikation erfolgt in Echtzeit, Rückkopplungsschleifen sind kurz. Das ist kein Zufall. Es ist gestaltet.

Führen durch Neugier

Am meisten beeindruckte mich nicht, was Jami wusste, sondern wie sie mit Nichtwissen umging. Neugierig. Humorvoll. Offen.

„Wenn ich zurückgehen könnte, würde ich mehr Fragen stellen. Ich würde mich nicht durch so vieles mit bloßer Kraft hindurcharbeiten.“

In einem Bereich, in dem technische Autorität oft wie auf einer Bühne inszeniert wird, ist ihr Führungsstil menschlich. Sie verbirgt ihren Lernprozess nicht. Sie betrachtet das Team als System, in dem emotionale Belastung ebenso zählt wie Timing-Vorgaben.

Die Kultur entscheidet oft über den Erfolg einer Technologie. Sie können brillante Ingenieure haben; wenn diese sich aber nicht trauen, Lücken zuzugeben, schöpfen Sie ihre Kreativität nicht aus. Neugier an der Spitze wirkt durch das ganze System.

Eine Philosophie für die Hardware der Zukunft

Entfernt man Abkürzungen und Prozessdiagramme, bleibt eine einfache Frage: Welche Welt bauen wir, wenn wir Hardware ausliefern?

Hardware bleibt. Sie braucht Raum, Strom und Aufmerksamkeit. Sie gibt ihren Nutzern einen Rhythmus vor. Sie prägt Erwartungen an Zuverlässigkeit und Reparatur. Sie lädt entweder zu verantwortlichem Umgang oder zu Verschwendung ein. Jedes Mal, wenn ein Team ein Design festschreibt, trifft es eine kleine Annahme darüber, wie Menschen mit diesem Objekt leben sollen.

Deshalb gehört Demut in den Prozess. Transparenz ist nicht nur eine Managementtechnik. Sie ist eine ethische Haltung. Sie sagt: Wir zeigen unsere Arbeit, laden Kritik ein und gestalten mit Blick auf die Zukunft, nicht nur auf den Marktstart.

Eine Philosophie für künftige Hardware könnte so lauten: Schaffen Sie Klarheit. Ziehen Sie Beobachtbarkeit cleveren Tricks vor. Treffen Sie Entscheidungen, die verborgene Kopplungen reduzieren. Behandeln Sie Stromversorgung, Timing und Sicherheit als vorrangig. Lassen Sie Raum für Reparaturen. Dokumentieren Sie Entscheidungen so, als würde jemand anderes sie übernehmen – denn das wird geschehen. Wählen Sie Werkzeuge und Architekturen, mit denen neue Ingenieure schnell mitreden können. Bevorzugen Sie Designs, die ein Mensch auch unter Druck nachvollziehen kann.

Bringen Sie vor allem Kultur und Physik in Einklang. Fördern Sie frühe Sichtbarkeit. Belohnen Sie ruhiges Problemlösen. Geben Sie Menschen genug Struktur, um mutig zu sein. Dann liefern wir mehr als Platinen. Wir vermitteln eine Arbeitsweise, die das Produkt überdauert.

Lektionen für Hardware Rich Development

Das Gespräch mit Jami machte einige Wahrheiten deutlich, die im Lieferdruck leicht vergessen werden.

• Transparenz ist unverzichtbar. Schweigen kostet in der Hardware zu viel. Teilen Sie früh, auch wenn noch Unordnung herrscht.
• Generalismus ist eine strukturelle Stärke. Die wertvollsten Ingenieure verbinden Fachgebiete und denken in Systemen. Tiefe bleibt wichtig, doch Breite schafft Widerstandsfähigkeit.
• Struktur ist Freiheit. Gute Systeme geben Ingenieuren Raum zum Denken statt die Last des Chaos.
• Neugier ist Führung. Zuzugeben, dass man etwas nicht weiß, schafft mehr Vertrauen als gespielte Gewissheit.
• Respektieren Sie den FPGA-Ablauf. Constraints, CDC, Resets und Rückverfolgbarkeit bestimmen Ihren Zeitplan stärker als jeder einzelne RTL-Block.

In vieler Hinsicht verkörpert Leaf Labs Hardware Rich Development. Nicht weil das Team mehr Abkürzungen anhäuft, sondern weil es Hardware als Schaltungen und als Kultur versteht. Es gestaltet Systeme aus Menschen ebenso sorgfältig wie Systeme aus Logik.

Vielleicht ist das die übergreifende Lehre für jede technische Führungskraft. Ingenieursarbeit ist immer Systemdenken. Die einzige Frage ist, welche Systeme Sie wahrnehmen wollen.

‍