Die gesamte Serie lesen
Dieser Artikel ist Teil einer ausführlichen Anleitung dazu, wie wir mit Quilters physikgestützter Layout-Automatisierung einen Computer auf Basis des NXP i.MX 8M Mini nachgebaut haben.
Positionen:
Director of Manufacturing Software & Test, Apple; Hardware Test Lead, Amazon Schwerpunkte: Fertigungstests, Produktauslieferung, Teamführung, Widerstandsfähigkeit von Designs
Wichtigste Erkenntnisse
- Testzeit ist Geld. Jede Sekunde Testzeit in der Fabrik kostet. Kluge Teams lernen, wann sie investieren und wann sie sparen sollten.
- Beziehungen sind Werkzeuge der Ingenieursarbeit. Die besten Testsysteme entstanden nicht nur durch Logik und Code, sondern durch Vertrauen und ein gemeinsames Verständnis.
- Führung ist keine Kontrolle. Gute Führungskräfte übertreffen nicht ihre Teams – sie bauen Teams auf, die sie selbst übertreffen.
- EQ ist wichtiger denn je. Die bleibende Lücke in der Ingenieursarbeit liegt in der emotionalen Intelligenz, nicht im technischen Können.
Hardware-Interviews per E-Mail erhalten
Hinter den Kulissen wird es ernst
Als Gastgeber von Hardware Rich Development spreche ich mit vielen Hardwareveteranen. Die meisten denken in Prozessen, sind technisch versiert und zutiefst pragmatisch. Doch gelegentlich trifft man jemanden, der genug gesehen, getan und reflektiert hat, um mit seltener Klarheit zu sprechen. Paul Robinson ist einer dieser Menschen.
Paul ist mehr als ein Testingenieur. Seine fünfunddreißigjährige Laufbahn, die sich überwiegend hinter den Kulissen abspielte, ist ein lebendiges Beispiel für konsequente Umsetzung: Fertigungssoftware schreiben, Diagnosewerkzeuge bauen und Systeme entwickeln, die kaum jemand sieht, von denen aber alle profitieren. Er verbrachte Jahrzehnte bei Apple, eine Zeit bei Amazons Lab126 und unzählige Nächte am Telefon mit China oder Irland, um die termingerechte Auslieferung sicherzustellen.
Jetzt, frisch im Ruhestand, reist er mit seiner Frau durch Europa und nimmt endlich den Urlaub, für den früher nie Zeit war.
Was folgt, ist nicht nur eine Zusammenfassung unseres Gesprächs. Es ist eine Reflexion darüber, was seine Erfahrung mich gelehrt hat und was sie der nächsten Generation von Hardwareingenieuren und Entwicklern mitgeben sollte.
Zufällig zum Test, mit Neugier nach oben
Paul hatte keine Laufbahn in Fertigung und Test geplant. Wie viele Ingenieure seiner Generation folgte er seiner Neugier. Er begann ein Architekturstudium, ließ sich aber von einem neuen Professor überzeugen, stattdessen Computer Engineering zu versuchen. So entwickelte er in seinen ersten Positionen Kommunikationsstrukturen für Militärdrohnen – Systeme, die bemerkenswerterweise möglicherweise bis heute im Einsatz sind.
Dann erhielt er einen Anruf von Apple. Eine Stelle im Testengineering.
„Ich wusste gar nicht richtig, was Testengineering ist“, sagte Paul, „aber ich hatte Erfahrung mit Elektronik und Software, und das passte.“
Das höre ich oft: Die besten technischen Laufbahnen entstehen bei Menschen, die in mehreren Gebieten gerade genug wissen. Diese vielseitige Neigung, die Bereitschaft, von allem etwas zu lernen, ist oft die beste Vorbereitung auf eine Zukunft, die niemand vorhersagen kann.
Testen als Verpflichtung, nicht als Nachgedanke
Pauls Haltung zum Testen wurde durch Apples Kultur geprägt. Bei Apple ist Testen keine Formalität am Ende. Es ist die entscheidende Phase im Produktlebenszyklus.
„Man liefert aus. Egal was passiert. Das war die Haltung“, erzählte er mir. „Wir strichen keine Funktionen. Wir brachten es einfach zum Laufen.“
Eine besonders anschauliche Geschichte handelte von der Apple Watch. Ein neuer Sensor erforderte in der Fabrik eine genaue Temperaturkalibrierung. Der erste Ansatz scheiterte. Schließlich verschlossen Paul und sein Team die Uhren in Ziploc-Beuteln und tauchten sie zur Kalibrierung in zirkulierendes Eiswasser. Es war unelegant. Es war absurd. Es funktionierte.
Da ich Unternehmen seit Jahren helfe, ihre technischen Geschichten zu erzählen, liebe ich dieses Beispiel. Es trifft den Kern der Ingenieursarbeit: den Moment, in dem Einfallsreichtum auf Grenzen trifft und das Team einen Weg findet. Pauls Geschichte war voller solcher Momente. Von zweckentfremdeten Sensoren bis zum Abwägen von Kosten und Präzision zeigte sich: Testen ist mehr als Überprüfung. Hier wird der Beweis erbracht.
Die Kosten der Testzeit, der Wert der Dringlichkeit
„Testzeit ist Geld.“
Das war eines von Pauls Mantras, und es saß. In einer Fabrik zählt jede Sekunde. Eine Minute Testzeit bedeutet Prüfgeräte, Bedienpersonal, Energie und Auswirkungen auf den Durchsatz. Und dennoch investiert man in den frühen Produktphasen großzügig, allein um sicherzugehen, dass das Produkt funktioniert.
Später, manchmal erst in der nächsten Generation, optimiert man. Die Testzeit sinkt von sechzig auf zehn Sekunden. So entstehen Margen. Das ist eines der besten Beispiele für bewusst eingegangene Schulden, die ich kenne: Für den Marktstart das Nötige tun und anschließend in Effizienz investieren.
Im Gespräch wurde mir klar, wie oft wir Optimierung mit Fortschritt verwechseln. Paul erinnerte mich daran, dass echter Fortschritt bedeutet, dem Kunden das Produkt zum versprochenen Zeitpunkt und mit der vorgesehenen Funktion zu liefern.
Führung bedeutet, das Ego loszulassen
Einer der menschlichsten Momente im Interview entstand, als Paul von seinen Anfängen als Führungskraft erzählte. Frustriert vom fehlerhaften Code eines Teammitglieds schrieb er ihn an einem Wochenende selbst neu. Der Code funktionierte besser. Doch die Beziehung nahm Schaden.
„Damals habe ich etwas gelernt“, sagte er. „Als Führungskraft ist es nicht Ihre Aufgabe, der beste Programmierer zu sein. Ihre Aufgabe ist es, ein Team aufzubauen, das besser ist als Sie.“
Dieser Satz blieb mir im Gedächtnis. Solche Einsichten stammen nicht aus Managementbüchern. Man gewinnt sie durch Fehler, indem man jemanden kleinmacht und erkennt, dass technische Exzellenz nichts bedeutet, wenn das Team einem nicht vertraut.
Ich habe sowohl als technischer Mitarbeiter als auch als Teamleiter gearbeitet und diese Dynamik immer wieder erlebt. Führung in der Ingenieursarbeit bedeutet nicht Kontrolle, sondern Befähigung. Sie sind nicht der Held. Sie vervielfachen die Wirkung des Teams.
Wenn großartige Hardware auf ein schlechtes Produkt trifft
Nicht jede Geschichte endete gut. Paul arbeitete an Amazons gescheitertem Fire Phone: ein Produkt mit solider Hardware und einer grundlegend mangelhaften Nutzererfahrung.
„Wir wussten alle, dass es nicht gut laufen würde“, sagte er. „Wir installierten Android auf unseren Testtelefonen, nur damit sie benutzbar waren.“
Ich war immer überzeugt, dass die besten technischen Teams auch das Produkt als Ganzes sehen können. Nicht nur sein Innenleben. Nicht nur die Stückliste. Das gesamte Erlebnis. Paul wusste das. Er nutzte das Fire Phone sogar als warnendes Beispiel beim Mentoring junger Ingenieure.
„Nur weil es gestern funktioniert hat, heißt das nicht, dass es heute funktioniert.“
Dieses Prinzip bleibt gültig. Es gilt für Werkzeuge, UX-Muster und interne Abläufe. Solche Einsichten unterscheiden Verwalter von Erneuerern.
Späte Lektionen über KI und Werkzeuge, die wachrütteln
Im letzten Jahr vor seinem Ruhestand wehrte sich Paul gegen große Sprachmodelle. Sein Chef fragte jede Woche nach Ideen. Paul hielt dagegen. Bis einer seiner Ingenieure LLMs auf Fabrikdaten anwandte und zuvor unmögliche Erkenntnisse gewann.
„Es war unglaublich. Plötzlich konnten wir echte Fragen an die Daten stellen.“
Der Wendepunkt war die Demonstration, nicht die Technologie. Dieser Moment der Klarheit unter Kollegen, dieses Zusammengehörigkeitsgefühl.
Als Marketer habe ich das aus einem anderen Blickwinkel erlebt. Folien überzeugen niemanden. Wirkung überzeugt alle. Zeigen Sie, was es kann. So ändern sich Einstellungen.
Was Ingenieuren fehlt – und schon immer fehlte
Trotz aller technischen Komplexität seiner Laufbahn endete Paul mit einer sehr menschlichen Diagnose dessen, was den meisten Ingenieursorganisationen noch fehlt.
„An guten Ingenieuren mangelt es nicht. Was fehlt, ist EQ. Kommunikation. Der Blick für das Ganze. Das war schon immer die Lücke.“
Das höre ich immer wieder von den besten technischen Führungskräften. Und trotzdem bilden wir nicht dafür aus. Wir konzentrieren uns auf neue Sprachen und Werkzeuge, belohnen aber nicht die Fähigkeit, Konsens herzustellen, Konflikte zu bewältigen oder Schwieriges verständlich zu erklären.
Das ist der Ingenieur der Zukunft. Und auch der Vergangenheit. Wer herausragte, war schon immer vielseitig.
Abschließende Gedanken: Die Dankbarkeit eines Menschen, der geliefert hat
In Pauls Laufbahn ging es nicht nur um die Auslieferung von Hardware. Es ging um den Aufbau von Teams, das Wachsen an Fehlern, zu viele Arbeitsstunden und schließlich darum, auch zum übrigen Leben Ja zu sagen.
Sein letzter Dank galt seiner Frau Grace, die ihre Kinder großzog, während er jahrelang telefonierte, in Fabriken arbeitete oder in Code versank.
„Ich war nie zu Hause. Und wenn ich da war, war ich nicht wirklich anwesend. Aber sie hielt zu mir.“
Pauls Geschichte bildet am Ende keinen perfekten Bogen. Sie ist keine makellose Erfolgserzählung. Sie ist echt. Unordentlich. Menschlich. Genau das macht sie wertvoll.
Diese Art von Ingenieursarbeit möchte ich in Hardware Rich Development zeigen: Arbeit, in der Code, Menschen und Konsequenzen aufeinandertreffen. Bei der die Menschen hinter dem Produkt genauso beeindruckend sind wie das Produkt selbst.
