Meine Tochter hat eine Woche als Praktikantin in unserem IT-Unternehmen gearbeitet. Das Ergebnis vorweg: ITlerin wird sie nicht. Aber die Woche hat etwas über Motivation und Aufgabenverteilung sichtbar gemacht, das für jedes Team relevant ist.
Die Ausgangslage
Es war ein Notpraktikum. Schülerpraktikum steht an, keine Bewerbung geschrieben, Deadline rückt näher. Papa hat eine Firma, also los. Keine große Begeisterung, keine besonderen Erwartungen.
Die Aufgaben in der Woche waren bewusst gemischt: 24 Netzwerkkabel mit Beschriftungsfähnchen versehen. Ein AWS-Systemdiagramm in Confluence neu aufbauen, mit Kästchen, Pfeilen und Verbindungen, damit es endlich pflegbar dokumentiert ist. Dazu administrative Kleinigkeiten.
Alles wurde zuverlässig erledigt. Keine Diskussion, keine Nachfragen zu Sinn und Zweck. Im Büro wurde geliefert. Interessant, denn zu Hause wird über deutlich kleinere Aufgaben verhandelt. Aber das ist vermutlich ein allgemeines Eltern-Phänomen und kein Management-Insight.
Der Moment, der etwas gezeigt hat
Dann kam eine Aufgabe, die nichts mit IT zu tun hatte: Tech-Icons auf die Glastür meines Büros malen, damit niemand dagegen läuft, wenn sie geschlossen ist.
Der Unterschied war sofort sichtbar. Bei den IT-Aufgaben war die Haltung „wird erledigt“. Bei den Icons war sie „wird gestaltet“. Kreativität, Eigeninitiative, Stolz auf das Ergebnis. Die Energie im Raum war eine andere.
Der Unterschied zwischen „erledigt“ und „mit Begeisterung gemacht“ war nicht graduell. Er war fundamental. Und er hatte nichts mit Fähigkeit zu tun. Beide Aufgabentypen waren machbar. Der Unterschied lag in der Verbindung zwischen Person und Aufgabe.
Was das für die Führung in Softwareteams bedeutet
In Unternehmen wird viel über Performance, Skills und Produktivität gesprochen. Weniger oft wird gefragt: Womit identifizieren sich die Menschen eigentlich? Wo bringen sie freiwillig Energie rein, die über das Pflichtprogramm hinausgeht?
In der Softwareentwicklung ist dieses Muster täglich zu beobachten. Ein Entwickler blüht bei komplexen Architekturthemen auf, ein anderer wird lebendig, wenn er direkt mit dem Kunden spricht. Jemand ist in seinem Element bei Code-Reviews und Qualitätssicherung, ein anderer bei der Automatisierung von Prozessen.
Alle können ihre zugewiesenen Aufgaben erledigen. Aber die Qualität und das Engagement sind messbar anders, wenn die Aufgabe zur Person passt. Das ist keine neue Erkenntnis, aber sie wird in der täglichen Praxis selten konsequent umgesetzt.
Die Gründe dafür sind nachvollziehbar: Aufgaben werden nach Verfügbarkeit verteilt, nicht nach Neigung. Deadlines lassen wenig Spielraum für optimale Besetzung. In kleineren Teams muss jeder alles machen. Das sind reale Einschränkungen.
Trotzdem lohnt es sich, innerhalb dieser Einschränkungen so viel Passung wie möglich herzustellen. Das bedeutet nicht, dass jeder nur noch das macht, was ihm Spaß macht. Es bedeutet, dass die Aufgabenverteilung die individuellen Stärken und Interessen berücksichtigt, wo immer es möglich ist. Der Aufwand dafür ist gering. Die Wirkung auf Engagement und Ergebnisqualität ist erheblich.
Fazit
Eine Woche Schülerpraktikum hat etwas verdeutlicht, das in der täglichen Teamarbeit leicht untergeht: Der Unterschied zwischen Aufgabenerledigung und Aufgabenidentifikation ist sichtbar, messbar und gestaltbar. Die Aufgabe der Führung ist nicht, alle in die gleiche Form zu pressen. Sie ist, herauszufinden, wo die Passung zwischen Person und Aufgabe am größten ist, und diese Passung aktiv zu gestalten.
Meine Tochter wird keine ITlerin. Aber sie hat in einer Woche etwas sichtbar gemacht, das in vielen Teams übersehen wird.
Vor 30 Jahren gehörte ich zu den ersten Klassen, die Informatik als Wahlfach belegen konnten. Es fühlte sich nach dem Beginn einer neuen Ära an. Computer werden Teil des Alltags, und die Schule bereitet darauf vor. Heute, nachdem ich zwei eigene Kinder durch die Oberstufe mit Wahlfach Informatik begleitet habe, fällt die Bilanz ernüchternd aus.
Die Entwicklung über drei Jahrzehnte
Vor 30 Jahren war die Begeisterung groß. Informatik als Pilotfach, die Erwartung, dass eine ganze Generation für Technologie begeistert wird, die Hoffnung auf eine Lösung des Fachkräftemangels. Die Euphorie war berechtigt: Digitalisierung war absehbar, und wer früh die Grundlagen versteht, hat später einen Vorteil.
Vor 5 Jahren dann der erste Frustmoment. Der Informatik-Unterricht meines ältesten Kindes begann mit dem Binärsystem. Nullen und Einsen, bevor auch nur klar war, warum Informatik relevant ist. Für Schüler, die täglich Smartphones nutzen, Apps herunterladen und soziale Netzwerke bedienen, war das eine abstrakte Welt ohne erkennbaren Bezug zu ihrer Lebenswirklichkeit.
Heute sieht die Realität so aus: Weniger als 10% der Schüler wählen Informatik. Wer es wählt und bereits programmieren kann, weiß vorher oft schon mehr, als die Lehrkraft vermitteln kann. Wer es wählt und keine Vorkenntnisse hat, wird durch den theorielastigen Einstieg eher abgeschreckt als motiviert. Bei schriftlichen Klausuren sitzt man mitunter allein im Raum.
Woran es scheitert
Informatik ist das Fach, das eigentlich den stärksten Bezug zur Lebensrealität von Jugendlichen haben müsste. Apps, Websites, KI, Automatisierung, alles, was sie täglich nutzen, basiert auf informatischen Grundlagen. Das Potenzial für Begeisterung wäre enorm.
Der Unterricht schafft es in den meisten Fällen nicht, dieses Potenzial zu heben. Das liegt nicht am Willen der Lehrkräfte, sondern an strukturellen Problemen.
Der Einstieg über Theorie: Binärsystem, Sortieralgorithmen, UML-Diagramme auf Papier. Diese Themen haben ihren Platz in der Informatik, aber nicht als Einstieg. Wer mit abstrakten Konzepten beginnt, bevor ein konkreter Anwendungsbezug hergestellt ist, verliert die meisten Schüler nach der ersten Doppelstunde. Es fehlt der „Aha-Moment“, der Neugier weckt.
Fehlende Sichtbarkeit der Ergebnisse: In Kunst entsteht ein Bild. In Musik entsteht ein Stück. In Sport misst man sich. In Informatik analysiert man Algorithmen auf Papier. Schüler brauchen sichtbare, anfassbare Ergebnisse, auf die sie stolz sein können. Eine eigene Website, eine kleine App, ein funktionierender Bot. Die Theorie gewinnt an Bedeutung, wenn sie im Kontext eines konkreten Projekts auftaucht, nicht vorher.
Die Lücke zwischen Lehrplan und Praxis: Informatik-Curricula ändern sich langsam. Die Technologie ändert sich schnell. Der Unterricht behandelt Konzepte, die wichtig sind (Algorithmen, Datenstrukturen), aber er schlägt selten den Bogen zur aktuellen Praxis. Wie funktioniert eine KI? Wie werden die Apps gebaut, die Schüler täglich nutzen? Wie schützt man seine Daten? Diese Fragen interessieren Jugendliche. Der Lehrplan beantwortet sie oft nicht.
Praxisnahe Lehrkräfte sind selten: Das ist vermutlich das schwierigste Problem. Wer Informatik studiert hat und in der Industrie deutlich mehr verdienen kann, wird selten Lehrer. Die Folge: Informatik wird häufig fachfremd unterrichtet, von engagierten Lehrkräften, die aber selbst keine tiefe Praxiserfahrung haben. Begeisterung für ein Fach entsteht am leichtesten durch jemanden, der selbst begeistert ist und aus der Praxis erzählen kann.
Was besser funktionieren könnte
Es gibt Schulen und einzelne Lehrkräfte, die Informatik-Unterricht machen, der Schüler begeistert. Die Muster, die dort funktionieren, sind erkennbar.
Mit sichtbaren Ergebnissen beginnen: Eine eigene Website bauen. Ein Spiel programmieren. Einen Chatbot erstellen. Etwas, das man vorzeigen kann, das auf dem eigenen Handy läuft, das Freunde nutzen können. Die Theorie folgt dann naturgemäß, weil Schüler verstehen wollen, warum etwas funktioniert oder nicht funktioniert.
Echte Probleme lösen lassen: Wie würdest du die Schulbibliothek digital organisieren? Wie könntest du den Vertretungsplan automatisieren? Projektbasierter Unterricht, bei dem Schüler ein reales Problem in ihrer Umgebung lösen, erzeugt eine ganz andere Motivation als die Implementierung eines Sortieralgorithmus auf dem Papier.
Praktiker einbinden: Kooperationen mit lokalen IT-Unternehmen, Gastvorträge von Entwicklern, gemeinsame Projekte. Das muss keine dauerhafte Stelle sein, aber regelmäßiger Kontakt zur Praxis gibt dem Unterricht eine Dimension, die das Lehrbuch allein nicht liefern kann.
Warum das auch die Wirtschaft betrifft
Der IT-Fachkräftemangel wird seit Jahrzehnten diskutiert. Gleichzeitig schafft es das Schulsystem nicht, eine relevante Anzahl von Schülern für Informatik zu begeistern. Beides hängt zusammen, auch wenn die Kausalität nicht direkt ist.
Die Schule ist nicht die einzige Quelle für IT-Nachwuchs. Aber sie ist der Ort, an dem die erste Berührung stattfindet. Wenn diese Berührung durch theorielastigen Unterricht abschreckend wirkt, gehen potenzielle Talente verloren, die sich unter anderen Umständen für einen technischen Weg entschieden hätten.
Wer als Unternehmen auf den Nachwuchs wartet, den die Schule für IT begeistert, wird lange warten. Die Begeisterung für Technik entsteht in den meisten Fällen trotz des Unterrichts, nicht wegen des Unterrichts. Das ist kein Vorwurf an einzelne Lehrkräfte. Es ist eine Bestandsaufnahme nach 30 Jahren, die zu der Frage führt, ob der strukturelle Rahmen geändert werden muss.
Fazit
Informatik als Schulfach hatte ein enormes Versprechen. 30 Jahre später ist klar, dass dieses Versprechen nicht eingelöst wurde. Nicht weil das Fach unwichtig wäre, sondern weil der Unterricht es zu selten schafft, die Brücke zwischen Theorie und Lebenswirklichkeit zu bauen. Die guten Beispiele zeigen, dass es anders geht. Die Frage ist, ob sie Ausnahmen bleiben oder zum Standard werden.
Ein BNC-Netzwerkkabel. Für viele heute nur noch ein Museumsstück. Für uns war es der Anfang. Dieses Kabel hat die ersten beiden Rechner bei COMINTO verbunden, vor mehr als 25 Jahren. Vor Ethernet, vor Cat5, vor allem, was heute als selbstverständlich gilt.
Was sich verändert hat
Die technologischen Sprünge der letzten 25 Jahre lassen sich in Fünf-Jahres-Zyklen einteilen, und jeder Zyklus hat die Branche grundlegend verändert.
Infrastruktur: Von lokalen Netzwerken mit BNC-Kabeln über Ethernet und Glasfaser bis zu globaler Cloud-Infrastruktur. Was vor 20 Jahren einen Serverraum, Hardware-Beschaffung und Netzwerk-Expertise erforderte, lässt sich heute in Minuten bei AWS, Azure oder Google Cloud bereitstellen. Die Einstiegshürde für IT-Infrastruktur ist praktisch verschwunden.
Geschwindigkeit der Release-Zyklen: Vor 20 Jahren wurde Software ein- bis zweimal pro Jahr released. Jede Auslieferung war ein Großereignis mit Wochenend-Einsätzen und Rückfallplänen. Heute deployen viele Teams mehrmals täglich. CI/CD-Pipelines, automatisierte Tests und Container-Technologie haben den Release-Prozess von einer riskanten Operation zu einer Routine gemacht. Das hat die Erwartungen an Liefergeschwindigkeit fundamental verändert.
Komplexität der Systemlandschaften: Ein modernes Softwareprojekt hat mehr bewegliche Teile als je zuvor. Mehr Frameworks, mehr Abhängigkeiten, mehr Schnittstellen, mehr Angriffsfläche. Die Fähigkeit, diese Komplexität zu beherrschen, statt sich von ihr treiben zu lassen, ist zur Kernkompetenz geworden. Wer vor 25 Jahren eine Webanwendung gebaut hat, musste eine Handvoll Technologien beherrschen. Wer heute eine vergleichbare Anwendung baut, muss sich in einem Ökosystem aus dutzenden Tools, Diensten und Bibliotheken zurechtfinden.
Entwicklungsmethodik: Von Wasserfall mit monatelangen Planungsphasen über Agile bis zu DevOps und KI-gestützter Entwicklung. Die Art, wie Software entsteht, hat sich in jeder Dekade grundlegend verändert. Geblieben ist eine Konstante. Jede neue Methodik löst reale Probleme, schafft aber neue. Agile hat die Starrheit von Wasserfall überwunden, manchmal aber auch die Disziplin der Planung. DevOps hat die Kluft zwischen Entwicklung und Betrieb geschlossen, dafür den Anspruch an das Kompetenzprofil jedes einzelnen Entwicklers erhöht.
Was sich nicht verändert hat
Bei allen technologischen Umbrüchen gibt es Konstanten, die sich über die gesamten 25 Jahre gehalten haben.
Vertrauen als Geschäftsgrundlage: Der erste Kunde hat uns vertraut, bevor wir irgendetwas bewiesen hatten. Ein Vierteljahrhundert später ist Vertrauen immer noch die Grundlage jeder Geschäftsbeziehung. Kein Tool, keine Zertifizierung und keine Technologie ersetzt das Vertrauen, das durch zuverlässige Lieferung über Jahre hinweg entsteht. Kunden beauftragen nicht Technologien, sie beauftragen Teams, denen sie zutrauen, ihr Problem zu lösen.
Menschen als differenzierender Faktor: Die Technologie hat sich alle fünf Jahre grundlegend verändert. Die Fähigkeit, zuzuhören, Probleme zu verstehen und gemeinsam Lösungen zu erarbeiten, ist dieselbe geblieben. Gute Teams liefern gute Ergebnisse, unabhängig vom Tech-Stack. Schlechte Teams scheitern, unabhängig davon, wie modern ihre Werkzeuge sind. Diese Erkenntnis klingt banal, wird aber in einer Branche, die Technologie vergöttert, regelmäßig vergessen.
Einfachheit als Erfolgsfaktor: Vor 25 Jahren war die einfachste Lösung die beste. Heute, mit hundertfach mehr Möglichkeiten, gilt das noch stärker. Die Versuchung, komplexe Lösungen zu bauen, weil die Werkzeuge es ermöglichen, war noch nie so groß. Und der Wert der bewusst einfachen Lösung war noch nie so hoch. Jede unnötige Komplexität ist eine zukünftige Wartungslast.
Durchhaltevermögen als unterschätzter Faktor: 25 Jahre sind eine lange Zeit in einer Branche mit hoher Fluktuation. Es gab Jahre, in denen alles glatt lief, und Jahre, in denen nichts funktioniert hat. Technologiewechsel, die das Geschäftsmodell in Frage stellten. Konjunktureinbrüche, die Projekte stoppten. Jedes Mal die Frage, ob es weitergeht. Rückblickend war die Fähigkeit, auch in schwierigen Phasen nicht aufzugeben, mindestens so wichtig wie jede technische Kompetenz.
Die Perspektive, die 25 Jahre geben
Wer 25 Jahre in der IT arbeitet, hat jeden Hype-Zyklus miterlebt. Jedes Mal hieß es: „Diesmal ist alles anders.“ Und jedes Mal war tatsächlich vieles anders, aber nicht alles.
Die Cloud hat das Hosting verändert, aber nicht die Frage, wie man gute Software baut. Agile hat die Projektmethodik verändert, aber nicht die Notwendigkeit, den Kunden zu verstehen. KI verändert gerade die Entwicklung, aber nicht die Tatsache, dass am Ende ein Mensch entscheiden muss, was gebaut werden soll und ob das Ergebnis das Problem löst.
Wer die Grundprinzipien beherrscht, Kundenverständnis, Qualitätsbewusstsein, Kommunikation, Einfachheit, überlebt jeden Technologiewechsel. Wer nur die aktuelle Technologie beherrscht, steht alle fünf Jahre vor einem Neuanfang. Das ist keine Geringschätzung technischer Kompetenz. Es ist die Beobachtung, dass technische Kompetenz auf einem stabilen Fundament aus Grundprinzipien aufbauen muss, um langfristig wirksam zu sein.
Fazit
Von einem BNC-Kabel und zwei Rechnern zu Cloud-Infrastruktur und KI-gestützter Entwicklung. Die technologische Reise der letzten 25 Jahre war enorm. Was diese Zeit gelehrt hat: Technologien wechseln in Fünf-Jahres-Zyklen. Die Grundprinzipien guter Software und guter Zusammenarbeit halten Jahrzehnte.
In einer Branche, in der Jobwechsel alle zwei bis drei Jahre die Norm sind, Technologien in Fünf-Jahres-Zyklen kommen und gehen und selbst etablierte Unternehmen innerhalb einer Dekade verschwinden können, sind 25 Jahre eine bemerkenswerte Zeitspanne. Nicht weil es ein besonderes Kunststück wäre, sondern weil die Voraussetzungen dafür, in der IT so lange zu bestehen, sich immer wieder grundlegend ändern.
Die Anfänge
Vor 25 Jahren war COMINTO nicht mehr als zwei Rechner, ein BNC-Netzwerkkabel und die Überzeugung, dass wir gute Software bauen können. Kein Business-Plan, kein Investor, kein Sicherheitsnetz. Die ersten Kunden haben uns eine Chance gegeben, bevor wir irgendetwas beweisen konnten.
Die ersten Jahre waren geprägt von langen Nächten, knappen Budgets und der Realität, dass jeder einzelne Auftrag existenziell wichtig war. Was damals zählte, war einfach. Zuverlässig liefern, pünktlich, in guter Qualität, sodass der Kunde zurückkommt. An diesem Grundprinzip hat sich in 25 Jahren nichts geändert.
Was 25 Jahre in der IT-Branche bedeuten
In dieser Zeitspanne haben wir jeden größeren Technologiewechsel mitgemacht. Von lokalen Netzwerken zu Cloud-Infrastruktur. Von Wasserfall-Methodik zu Agile und DevOps. Von manueller Entwicklung zu KI-gestütztem Coding. Jeder dieser Wechsel hat Unternehmen verschwinden lassen, die sich nicht angepasst haben oder nicht schnell genug anpassen konnten.
Die Fähigkeit, sich technologisch weiterzuentwickeln, ist eine notwendige Bedingung für das Überleben. Aber sie reicht nicht aus. Viele Unternehmen, die technisch auf dem neuesten Stand waren, sind trotzdem gescheitert, weil sie die Kundenbedürfnisse aus den Augen verloren haben oder weil das Team auseinandergefallen ist.
Was sich bewährt hat, ist eine Balance: Neue Technologien lernen und einsetzen, ohne Bewährtes über Bord zu werfen. Trends prüfen, ohne jedem Trend zu folgen. Sich weiterentwickeln, ohne die eigene Identität zu verlieren. Das klingt nach einer Binsenweisheit, aber in der Praxis ist es eine tägliche Abwägung, die selten einfach ist.
Menschen und Beständigkeit
Das Bemerkenswerteste an 25 Jahren COMINTO sind nicht die Technologien und nicht die Projekte. Es sind die Menschen und die Dauer ihres Engagements.
Ein Kollege, der als Praktikant angefangen hat, „einfach mal reinschnuppern“, und 25 Jahre geblieben ist. Nicht weil es keine Alternativen gegeben hätte. In der IT-Branche gibt es immer Alternativen, oft mit höherem Gehalt, moderner klingenden Projekten, größeren Namen auf dem Briefkopf. Er ist geblieben, weil aus Kollegen ein vertrautes Miteinander geworden ist und die Arbeit über all die Jahre Sinn ergeben hat.
Das ist kein selbstverständlicher Zustand. Er entsteht nicht durch Benefits, Tischkicker oder Obstschalen. Er entsteht durch echte Wertschätzung, durch Vertrauen und durch das gemeinsame Überstehen schwieriger Phasen. Und davon gab es genug: Konjunktureinbrüche, gescheiterte Projekte, Technologiewechsel, die alles in Frage stellten. Beständigkeit zeigt sich nicht in den guten Jahren. Sie zeigt sich in den schwierigen.
Die Feier
Als wir den Meilenstein erreicht haben, haben wir eine bewusste Entscheidung getroffen: Wir nehmen uns Zeit, um uns zu feiern. Richtig. Mit dem gesamten Team auf einer Kreuzfahrt von Kiel über Aarhus nach Kopenhagen und zurück. Drei Tage mit Fahrradtouren, Sightseeing und Zeit füreinander.
Keine Powerpoint-Präsentation über die Strategie der nächsten fünf Jahre. Kein Workshop, der als Feier getarnt ist. Einfach zusammen sein und die Tatsache anerkennen, dass 25 Jahre gemeinsamer Weg eine besondere Leistung sind. Von allen Beteiligten.
Was bleibt
25 Jahre haben bestimmte Überzeugungen verfestigt.
Technologie ist das Werkzeug, nicht das Ziel. Das Ziel ist, Kundenprobleme zu lösen. Die Technologie, mit der das geschieht, ändert sich alle fünf Jahre. Die Fähigkeit, zuzuhören und zu verstehen, was der Kunde wirklich braucht, ändert sich nicht.
Vertrauen baut sich langsam auf und schnell ab. Jeder Auftrag, der pünktlich und in guter Qualität geliefert wird, fügt ein Stück hinzu. Ein einziger gravierender Fehler kann Jahre an aufgebautem Vertrauen zerstören. Das Bewusstsein dafür muss in jedem Projekt präsent sein.
Die Technologie wird sich in den nächsten 25 Jahren stärker verändern als in den letzten. KI wird die Softwareentwicklung transformieren. Cloud wird endgültig zum Standard. Neue Plattformen werden entstehen und wieder verschwinden. Was bleiben wird: Die Notwendigkeit, Probleme zu verstehen. Die Bedeutung von verlässlichen Teams. Und der Wert von Menschen, die zusammenarbeiten, weil sie es wollen, nicht weil sie keine Alternative haben.
Als Windows 10 das Ende seiner Lebenszeit ankündigte, standen wir vor einer Infrastrukturentscheidung, die sich als deutlich aufwändiger herausstellte als erwartet. Nicht wegen der technischen Komplexität, sondern wegen der emotionalen Beteiligung aller Beteiligten.
Die Ausgangslage
Windows 10 läuft aus. Die Frage war einfach formuliert: Welches Betriebssystem nutzen wir künftig? Die Optionen: Windows 11, Apple (macOS) oder Linux.
Jede Option hat klare technische Vor- und Nachteile. Windows 11 bedeutet den geringsten Migrationsaufwand, aber mehr Cloud-Integration und damit mehr Abhängigkeit von Microsoft-Diensten. Apple bietet eine starke Entwicklerumgebung und hochwertige Hardware, ist aber teurer und erfordert eine komplett andere Administration. Linux bietet maximale Kontrolle und keine Lizenzkosten, ist aber für Nicht-Entwickler oft ungeeignet und schränkt die Auswahl an Business-Software ein.
Soweit die sachliche Analyse. Was dann passierte, war alles andere als sachlich.
Warum Betriebssystem-Entscheidungen emotional werden
Jeder im Team hatte jahrelange Gewohnheiten aufgebaut. Tastenkombinationen, Workflows, bevorzugte Tools, eingespieltes Muskelgedächtnis. Ein Betriebssystemwechsel bedeutet nicht nur neue Software. Er bedeutet, eingespieltes Arbeitsverhalten aufzugeben und neu zu lernen. Das fühlt sich nach Kontrollverlust an, auch wenn es rational betrachtet ein beherrschbarer Prozess ist.
Die Meinungen im Team waren klar getrennt. Die Windows-Nutzer argumentierten mit Gewohnheit und Kompatibilität. Die Entwickler, die für bestimmte Projekte ohnehin Apple-Hardware nutzten, sahen die Gelegenheit, auf ein einheitliches Apple-Setup umzusteigen. Die IT-Administration warnte vor den Kosten einer gemischten Umgebung.
Jede Position war aus der jeweiligen Perspektive nachvollziehbar. Was fehlte, war ein gemeinsamer Bewertungsrahmen, der die verschiedenen Aspekte vergleichbar macht.
Der Bewertungsrahmen
Um die Diskussion zu versachlichen, haben wir drei Kriterien definiert.
Migrationsaufwand: Was kostet der Wechsel in Arbeitsstunden, Schulung und produktivitätsfreier Zeit? Windows 11 liegt hier deutlich vorn: Migration innerhalb eines Tages, keine Umschulung nötig, alle bestehenden Tools laufen weiter. Apple erfordert Hardware-Tausch, Software-Neubeschaffung und eine Einarbeitungsphase von mehreren Wochen. Linux liegt dazwischen, je nach gewählter Distribution.
Administrationsaufwand im laufenden Betrieb: Zwei Betriebssysteme parallel zu verwalten verdoppelt den Admin-Aufwand: Lizenzen, Updates, Sicherheitsrichtlinien, Support-Know-how, alles in doppelter Ausführung. Einheitlichkeit hat einen echten, bezifferbaren Wert, auch wenn sie nicht die spannendste Entscheidungsgrundlage ist.
Langfristige Abhängigkeiten: Windows 11 erhöht die Bindung an das Microsoft-Ökosystem, insbesondere durch die stärkere Cloud-Integration. Für ein Unternehmen, das sensible Kundendaten verarbeitet, ist die Frage nach Datenhoheit nicht trivial. Apple schafft eine Abhängigkeit von der Hardware-Preispolitik eines einzelnen Herstellers. Linux minimiert Abhängigkeiten, erhöht aber den internen Aufwand.
Die Entscheidung
Wir haben uns für Windows 11 entschieden. Nicht aus Begeisterung, sondern aus Pragmatismus. Der Migrationsaufwand war am geringsten, das Team konnte sofort weiterarbeiten, und die Risiken durch die erweiterte Cloud-Integration ließen sich durch Konfiguration eingrenzen.
Für Entwicklungsprojekte, die Apple-Hardware erfordern, bleiben Macs dort, wo sie fachlich begründet sind. Keine Einheitlichkeit um jeden Preis, aber auch kein Wildwuchs.
Die wichtigste Erkenntnis aus dem Prozess. Bei solchen Entscheidungen geht es nicht darum, das objektiv „beste“ System zu finden. Es gibt kein objektiv bestes System. Es geht darum, die Lösung zu finden, die unter den konkreten Rahmenbedingungen aus Teamgröße, vorhandener Infrastruktur, fachlichen Anforderungen und Budget am wenigsten Reibung verursacht.
Übertragbare Erkenntnisse
Auch wenn die spezifische Entscheidung (Windows vs. Apple vs. Linux) nicht auf jedes Unternehmen übertragbar ist, sind die Prozess-Erkenntnisse allgemeingültig:
Emotionen anerkennen, aber nicht entscheiden lassen: Betriebssystem-Präferenzen sind tief verankert. Das zu ignorieren führt zu Widerstand. Aber die Entscheidung muss auf sachlichen Kriterien basieren. Die Emotionen gehören in die Diskussion, nicht in die Entscheidungsmatrix.
Einheitlichkeit hat einen messbaren Wert: Jede zusätzliche Plattform multipliziert den Verwaltungsaufwand. Das klingt nach einem langweiligen Argument, aber es ist einer der größten Hebel für IT-Effizienz in kleineren Unternehmen.
Nicht alles auf einmal ändern: Ein Betriebssystemwechsel ist genug Veränderung. Gleichzeitig neue Tools einzuführen oder Prozesse umzustellen, addiert Risiko, ohne dass es nötig wäre. Änderungen sequentiell umsetzen, nicht parallel.
Die Entscheidung dokumentieren: Nicht nur das Ergebnis, sondern auch die Kriterien und die Abwägung. In drei Jahren wird jemand fragen, warum diese Entscheidung so getroffen wurde. Dann hilft eine nachvollziehbare Dokumentation mehr als die Erinnerung an eine hitzige Teamdiskussion.
Fazit
Betriebssystem-Entscheidungen in Unternehmen berühren Gewohnheiten, Identität und Arbeitsabläufe gleichzeitig. Das erklärt, warum sie emotional geführt werden. Der Weg zu einer guten Entscheidung führt über einen sachlichen Bewertungsrahmen, der die verschiedenen Aspekte vergleichbar macht, und über die Akzeptanz, dass die pragmatischste Lösung selten die aufregendste ist.
Sie sehen gerade einen Platzhalterinhalt von Facebook. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von Instagram. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von X. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
