Ihre besten Entwickler arbeiten nicht in der IT

Irgendwo in Ihrem Unternehmen gibt es ein Ticket wie dieses.

Es wurde im März 2023 erstellt. Es fordert etwas Bescheidenes: einen Bildschirm mit den Zahlen, die ein Team jede Woche ansieht. Die Priorität ist "Mittel" und hat sich nie geändert. Das Zuweisungsfeld ist leer. Darunter hat die Person, die es geöffnet hat, dreimal höflich gefragt, ob es noch auf dem Fahrplan steht. Die letzte dieser Fragen war im Juni 2026. Niemand antwortete.

In der Zwischenzeit erstellt das Team denselben Bericht jeden Montagmorgen manuell in einer Tabelle.

Niemand in dieser Geschichte hat etwas falsch gemacht. Die IT-Abteilung ist nicht faul — sie ist mit Dingen beschäftigt, die wirklich wichtiger sind als ein Dashboard. Die Person, die das Ticket eröffnet hat, verlangt nicht viel — sie hat einfach aufgegeben. Der Prozess funktionierte genau so, wie er entworfen wurde. Das ist das Problem, das es wert ist, untersucht zu werden.

Die Übersetzungssteuer

So wird normalerweise interne Software erstellt.

Jemand hat ein Bedürfnis. Sie übersetzen dieses Bedürfnis in eine schriftliche Anfrage und verwandeln fachliches Wissen in Worte, die jemand aus einem anderen Berufsfeld interpretieren muss. Die Anfrage landet in einer Warteschlange, wo sie mit allem anderen konkurriert, wofür die IT verantwortlich ist — und das meiste davon ist kritischer. Monate später baut jemand, der diese Arbeit nicht macht, ein Werkzeug für Menschen, die das tun, basierend auf einem Dokument, das von jemandem geschrieben wurde, der keine Software erstellt. Das Ergebnis ist eine Annäherung. Wenn es ankommt, hat sich der Prozess, für den es gebaut wurde, geändert. Und um eine Korrektur zu bitten, bedeutet, von vorne bei Schritt eins zu beginnen.

Jede Übergabe in dieser Kette kostet Informationen. Wir haben die Kette trotzdem gebaut, weil es fünfzig Jahre lang keine Alternative gab: die Person mit dem Bedürfnis konnte nicht bauen, und die Person, die bauen konnte, hatte das Bedürfnis nicht.

Diese Einschränkung gilt nicht mehr. Durch AI-unterstützte Entwicklung ist es möglich geworden, dass ein kompetenter Fachmann ohne Programmierhintergrund funktionierende interne Werkzeuge erstellt. Nicht jedes Werkzeug, und nicht ohne Aufsicht — darauf kommen wir zurück. Aber die Einschränkung, die die gesamte Kette rechtfertigte, ist weg, und ein Prozess, der um eine nicht mehr existierende Einschränkung herum aufgebaut ist, ist nur noch Ballast.

Der Kunde war die ganze Zeit im Gebäude

Interne Software hat Kunden. Wir nennen sie nur nicht so. Wir nennen sie Benutzer oder "das Geschäft", als wären sie eine Abteilung, die Forderungen stellt, anstatt die Menschen, für die das Produkt da ist.

Schauen Sie, wer sie wirklich sind. Es sind Fachleute mit zehn oder zwanzig Jahren Erfahrung in ihrem Bereich. Sie kennen ihren Prozess besser als jeder andere im Unternehmen. Sie wissen, welche drei Zahlen auf einen Bildschirm gehören und warum die vierte nur Lärm ist. Sie kennen die Ausnahmen, die Randfälle und die kleinen täglichen Reibungspunkte, die in einem Anforderungsdokument nie überleben, weil sie zu unbedeutend klingen, um aufgeschrieben zu werden.

In kommerzieller Software investieren Sie enorme Anstrengungen, um Ihren Kunden so gut zu verstehen. In der internen Software sitzt dieses Verständnis bereits an einem Schreibtisch im zweiten Stock. Jahrzehntelang haben wir es bei der Übersetzung weggeworfen.

Jetzt kann diese Person das Ding selbst bauen. Direkt. Der Mittelsmann verschwindet — und wir sagen das mit Respekt, denn der Mittelsmann war nie das Problem. Die Übersetzung war es.

Es geht nicht darum, Ihre IT-Abteilung zu ersetzen

Jedes Mal, wenn dieses Thema aufkommt, hört jemand "feuern Sie die Entwickler." Das ist die falsche Schlussfolgerung, und danach zu handeln ist der Weg, wie Unternehmen das sehr falsch machen.

In diesem Modell schrumpft die IT nicht. Sie bewegt sich weiter oben im Stapel. Der Job hört auf, "jedes Stück Software im Unternehmen zu schreiben" und wird zu "es möglich machen, dass alle anderen Software sicher schreiben können." Konkret bedeutet das vier Dinge.

**Die Grundlage besitzen.** Architektur, Umgebungen, Datenzugriff, Bereitstellung, Authentifizierung. Niemand im Marketing sollte erfinden, wie ein Werkzeug mit dem Datenlager verbunden wird. Richten Sie das einmal richtig ein, und alles, was darauf aufbaut, erbt es.

**Die Grenzen festlegen.** Entscheiden Sie explizit, was Mitarbeiter bauen dürfen und was nicht. Welche Daten berührt werden dürfen, was ein System niemals verlassen darf, wo ein Werkzeug laufen darf. Aufgeschrieben, nicht angenommen.

**Überprüfen, was gebaut wird.** Nicht jede Änderung, aber ein echter Kontrollpunkt, bevor irgendetwas mit gemeinsamen Daten in Berührung kommt oder für die Arbeit eines Teams tragend wird.

**Lehren.** Dies wird der größte Teil der Rolle und der wertvollste. Ihre Entwickler wissen bereits, wie Gut aussieht. Diese Einschätzung auf zwanzig Fachexperten zu übertragen, vervielfacht sie auf eine Weise, wie das Schreiben des elften internen Dashboards in diesem Quartal es niemals tun wird.

Ganz ehrlich, das ist ein interessanterer Job als der, den die meisten internen Entwickler heute haben.

Was schief geht und wie man es vermeidet

Wir sagen Ihnen lieber von vornherein die Ausfallmodi, als dass Sie sie entdecken.

**Schatten-IT mit besseren Werkzeugen.** Bringen Sie das mit Begeisterung und ohne Regeln heraus, und in einem Jahr werden Sie zweihundert Werkzeuge haben, von denen niemand weiß, dass sie existieren, die Daten berühren, die niemand genehmigt hat. Die Antwort ist Governance, festgesetzt, bevor das erste Werkzeug gebaut wird — nicht danach.

**Der Bus-Faktor.** Ein Werkzeug, das von einer Person gebaut wurde, ist eine Abhängigkeit von dieser Person. Standards, Dokumentation und explizite Verantwortlichkeit müssen von Anfang an Teil des Modells sein, oder Sie erzeugen sehr effizient technischen Schulden.

**Die falschen Dinge bauen.** Alles, was mit Geld, persönlichen Daten, regulierten Prozessen oder Produktionssystemen zu tun hat, bleibt bei den Profis. Der nützliche Test ist nicht "kann AI das bauen?", sondern "was passiert, wenn das drei Monate lang stillschweigend falsch ist?" Wenn die Antwort ernst ist, ist es kein Kandidat.

**Zu groß anfangen.** Das Versagensmuster ist ein unternehmensweites Programm, das in einem Mitarbeitergespräch angekündigt wird. Das Muster, das funktioniert, ist ein Team, ein echtes Problem, ein Werkzeug, sechs Wochen — dann zeigen Sie das Ergebnis allen anderen.

Ein Unternehmen, das diese Schritte überspringt, wird eine schlechte Erfahrung machen und zu dem Schluss kommen, die ganze Idee funktioniere nicht. Es war nicht die Idee.

Wie man anfängt

Wenn Sie das testen möchten, ohne etwas Bedeutsames darauf zu setzen, ist die Abfolge einfach.

Wählen Sie eine Abteilung mit sichtbarem Rückstandsproblem — das Team mit der Montagmorgen-Tabelle ist meist der richtige Kandidat. Wählen Sie zwei oder drei Personen darin aus, die von ihren Kollegen respektiert und neugierig statt technisch sind. Lassen Sie die IT die Grundlage vorbereiten und die Grenzen festlegen, bevor jemand etwas baut. Lassen Sie diese Personen ein Werkzeug bauen, das sie persönlich benötigen, mit einem Entwickler zur Verfügung für Fragen und einer Überprüfung, bevor es live geht. Dann messen Sie die einzig wichtigen Dinge: wurde es genutzt, was hat es ersetzt, und wie lange dauerte es im Vergleich zu dem Ticket, aus dem es stammt.

Innerhalb von zwei Monaten werden Sie wissen, ob dies in Ihrer Organisation funktioniert. Das ist eine viel kleinere Frage als "sollen wir verändern, wie wir Software entwickeln", und sie ist beantwortbar.

Wo wir ins Spiel kommen

Das ist, was YourLastDev macht. Wir richten die professionelle Architektur und die Regeln zuerst ein — die Grundlage, die Grenzen, den Überprüfungsprozess — und dann schulen wir die Menschen, die bereits das Fachwissen haben, darauf selbst aufzubauen.

Der Name ist die These. Das Ziel ist, der letzte Entwickler zu sein, den Sie für diese Kategorie von Arbeiten einstellen, und der erste AI-Trainer, den Sie stattdessen hinzuziehen.

Der Experte in Ihrem Unternehmen steht bereits auf Ihrer Gehaltsliste. Sie beschreiben das Werkzeug, das sie benötigen, seit drei Jahren in einem Ticket, auf das niemand geantwortet hat.

Es ist wahrscheinlich an der Zeit, sie es bauen zu lassen.