Oft höre ich Leute über Karriere wie über eine Treppe sprechen. Eine Stufe nach der anderen, ein Titel nach dem anderen, am Ende eine Art geschlossener Sinn. Ich blicke auf meine und muss schmunzeln, weil ich keine Treppe sehe. Ich sehe eine Folge verschiedener Räume, jeder mit einem Fenster auf einen Teil des IT-Service-Marktes.
Keine Motivationserzählung. Eher eine Notizbuch-Anatomie. Im Rückblick stelle ich fest, dass mir jede Phase eine andere Linse hinterlassen hat. Heute, als Head of Tech und Partner in einem kleinen ICT-Haus, beginnen sich diese Linsen wirklich zu überlagern.
Das Seltsame nichtlinearer Karrieren
Lineare Karrieren gab es vielleicht nie wirklich, eine Weile haben wir’s geglaubt. Ich jedenfalls. Dann landete ich vom Interface Developer in einer der größten europäischen Luxus-E-Commerce-Gruppen (vor dem Eintritt in die Richemont-Sphäre) als CTO in einer Deep-Tech-Startup für Oil & Gas, bis hin zur Steuerung eines vielfältigen Projekt-Portfolios in einem Unternehmen mit rund zehn Personen.
Was diese Stationen verbindet, ist nicht die Technologie. Sie wechselt — schneller, als wir zugeben mögen. Der rote Faden liegt anderswo: jede Rolle ließ mich sehen, wie IT-Services gekauft und verkauft werden. Und vor allem, warum scheinbar technische Entscheidungen es selten sind.
Phase 1: in einem großen Player, von der Code-Seite
Wenn du in einer Großorganisation bist und nicht im Management, kannst du glauben, gewisse Dynamiken gingen dich nichts an. Tatsächlich durchziehen sie dich trotzdem — du erlebst sie nur reflektiert. Ich war im Code, aber in einem Konzern dieser Größe siehst du Dinge, die von außen unsichtbar bleiben.
Etwa, wie man die Beziehung zu Tech-Lieferanten wirklich managt. Nicht in der Theorie, nicht im Deck, sondern im Alltag. Ich sah, dass hinter einer Architekturentscheidung oft eine organisatorische, eine budgetäre, manchmal eine Machtfrage steckt. Und einen Unterschied, der mich anfangs störte und der einfach real ist: ein wegen Kompetenz gewählter Vendor und ein aus vertraglicher Trägheit gewählter Vendor sind nicht dasselbe — auf dem Papier wirken sie identisch.
Die erste Regel, die mir aus dieser Phase blieb — vielleicht etwas zynisch, aber wahr:
Der beste Lieferant ist nicht der mit der besten Proposition, sondern der, der die Organisation des Kunden versteht.
Schwer in ein Framework zu pressen. Qualitativ, kontextuell. Erfordert ein Verständnis interner Dynamiken, das oft nur durch Anwesenheit erworben wird. Ich frage mich noch heute, wie viele Ausschreibungen scheitern, nicht weil der Anbieter unfähig wäre, sondern weil er das „Nervensystem“ des Kunden nicht gelesen hat.
Phase 2: die Startup, also der echte Preis von Entscheidungen
Der Sprung in die Startup hat mich ohne Übertreibung am stärksten verändert. Als CTO einer Deep-Tech-Startup vertikal in Oil & Gas tat ich alles. Stack, Hiring, Prozesse, Budget, Kunden, Delivery. Alles zugleich, oft am selben Tag.
Und dort lernst du, was im Konzern verwaschen bleibt: der Preis von Entscheidungen ist nicht abstrakt. Er ist sofort. Jede Wahl hat unmittelbare Wirkung auf G&V, Time-to-Market, Tragfähigkeit des Teams.
Ich lernte, IT-Services nicht „nach Markt“ zu bepreisen, sondern nach realer Kostenstruktur. Klingt banal — bis du dagegen prallst. Ich lernte: ein zu niedrig bepreister Service ist gefährlicher als ein zu teurer, denn früher oder später zahlt jemand die Differenz. Meist der Kunde — in technischer Schuld, Verzug, Fluktuation, hektischen Patches.
Wichtig waren auch die Verträge. Nicht jene, die einen Verhandlungs-Sieg sichern, sondern jene, die Arbeit erlauben. Ich verstand: es gibt Verträge, die „schützen“, und Verträge, die „funktionieren“. Erstere sind voller Strafen, die niemand anwenden will. Zweitere definieren ausgerichtete Anreize — eine Kooperationszone, in der beide Seiten ein Interesse am Richtigen haben.
Die zweite Regel wurde fast zur Überzeugung:
Die Qualität eines IT-Service entscheidet sich vor Projektstart — in Architekturentscheidungen und in den Prozessen, die der Anbieter aufzieht.
Sobald der Code fließt, sind viele Spiele schon gespielt. Nicht alle. Aber viele.
Phase 3: das Multi-Kunden-Portfolio, wo Grenzen verschwimmen
Heute arbeite ich in einem kleinen ICT-Haus, etwa zehn Personen, als B2B-Tech-Partner. Kundschaft von Großkonzernen bis öffentlichen Verwaltungen. Meine Rolle ist eine Dauerkreuzung aus technischer Führung, Sprint-Planung, DevOps, Compliance und Architektur. Vor allem ist es Portfolio-Arbeit, also viele unterschiedliche Kontexte parallel.
Im selben Zeitraum können wir an einem regionalen Gesundheits-Informationssystem, einer SaaS-People-Analytics-Plattform, einer industriellen IoT-Infrastruktur, an Cybersecurity-Services als zertifizierter Partner eines führenden Vendors, an Compliance-Projekten und an Custom-Entwicklung für die öffentliche Hand arbeiten.
Hier greifen die zwei vorherigen Phasen ineinander. Einerseits das Konzern-Gedächtnis: ich verstehe, wie Enterprise-Kunden denken, was sie wirklich umtreibt, welche impliziten Zwänge wirken. Andererseits die Startup-Sensibilität: ich weiß, was Effizienz mit knappen Ressourcen heißt — und wie sehr Automatisierung und operative Disziplin zählen.
Aber die neue, unerwartete Lektion ist anders.
Der Markt der IT-Services ist auf eine Weise fragmentiert, die viele Advisory-Frameworks nicht erfassen.
Wir sind kein generalistischer System Integrator, aber auch keine Hyper-Spezial-Boutique. Wir sind dieses unbequem zu etikettierende Ding: ein agiler Tech-Partner mit Querschnittskompetenzen. In manchen Kontexten konkurrieren wir mit zehnmal größeren Playern — nicht weil wir absolut „besser“ wären, sondern weil unsere Prozesse schlanker sind und, zunehmend, weil AI-assistierte Entwicklung das Verhältnis zwischen Produktionskapazität und Teamgröße verändert.
Vielleicht wurde mir hier klar, wie sehr Karte und Gelände auseinanderfallen. In Quadranten und Reports sind manche Kategorien klar. Im realen Leben viel weniger.
Was diese Phasen mich übers IT-Sourcing gelehrt haben
Wenn ich das in praktische Implikationen übersetze, fallen mir drei Punkte ein — drei wiederkehrende „Defekte“ in der Anbieterbewertung.
Erstens, aus dem Konzern: Sourcing-Entscheidungen sind oft organisatorische Entscheidungen, getarnt als technische. Wer Advisory macht, sollte die internen Dynamiken des Kunden so gut verstehen wie die Capabilities des Anbieters. Sonst empfiehlt er den „Besten auf dem Papier“ und bekommt den Schlechtesten in der Praxis.
Zweitens, aus der Startup: die Ökonomie der IT-Services ist viel feiner als in Marktreports. Die Marge eines Anbieters auf einem Projekt kann je nach Architektur, Automatisierung, Prozessreife stark schwanken. Ohne diese Dynamik zu lesen, schützt man den Kunden nicht wirklich. Nur formal.
Drittens, aus dem Portfolio: der reale Markt ist diverser, als Frameworks suggerieren. Tech-KMU, die das europäische Wirtschaftsgewebe bedienen, tauchen oft in keinem Quadranten auf — liefern aber einen erheblichen Teil der IT-Services. Wer dieses Segment nicht kennt, gibt dem Kunden eine unvollständige Optionsmenge. Vielleicht ohne es zu merken.
Der kumulative Wert, und warum er jetzt zählt
Es gibt ein Muster bei Karrieren, die „unkonventionellen“ Wert produzieren. Nicht die einzelne Erfahrung macht den Unterschied, sondern die Schnittmenge.
Eine Analystin, die nur Consulting gemacht hat, kennt Frameworks, hat aber Delivery in Krisen vielleicht nie erlebt. Ein Techniker, der nur Dev gemacht hat, kennt den Code, aber nicht immer das Business. Eine Managerin, die nur Konzern gemacht hat, kennt Politik, verliert aber oft den Bezug zu echten Kosten und operativer Mühe.
Der Sinn meiner Bahn, falls einer existiert, ist das Durchqueren dieser Welten. Diese Verbindungsfähigkeit ist heute kein „Plus“ mehr. Mit KI in den Prozessen, härter werdender EU-Compliance, sich wandelnden Pricing-Modellen, Reshoring und neuen Erwartungen an Sicherheit und Datensouveränität — Komplexität nimmt zu, nicht ab.
Und wenn Komplexität zunimmt, werden einfache Antworten verdächtig.
Der nächste Schritt, mit etwas Ehrlichkeit
In letzter Zeit habe ich das Gefühl, die natürliche Evolution dieses Wegs sei, diese integrierte Perspektive zu jenen zu bringen, die Sourcing-Entscheidungen mit hoher Tragweite treffen.
Nicht als operativer Berater — das mache ich schon. Eher als Marktanalyst, Researcher, strategischer Advisor. In einem Kontext, in dem operative Tiefe und das Erzeugen handlungsleitender Insights den Kern des Wertangebots bilden.
Eine Rolle, die manche Firmen mit viel Mühe und Investitionen versuchen, gut zu verkörpern.
Nicht weil ich die richtigen Antworten hätte. Bei vielem habe ich, ehrlich, nicht einmal eine eindeutige Antwort. Aber ich glaube, die richtigen Fragen zu haben — die, die aus dem Sehen des IT-Service-Marktes aus mehreren Winkeln stammen. Vielleicht ist genau das, was heute am meisten fehlt.
Nächster in der Reihe: wie die EU-Regulierungswelle die Bewertungskriterien für IT-Anbieter neu definiert — und warum der Advisory-Markt noch nicht bereit ist.
Was du mitnimmst
Vom großen Player: Sourcing-Entscheidungen sind fast immer organisatorische Entscheidungen, getarnt als technische.
Aus der Startup: die Qualität eines IT-Service entscheidet sich vor Projektstart, in Architektur und Prozessen.
Aus dem Portfolio: der reale Markt ist fragmentierter, als es Quadranten erfassen können.
Der beste Anbieter ist nicht der mit dem besten Angebot, sondern der, der versteht, wie die Organisation des Kunden funktioniert.
Wenn Komplexität wächst, werden einfache Antworten verdächtig.
Fragen & Antworten
Warum ist eine Karriere in IT-Services selten linear?
Weil jede Phase eine andere Linse auf den Markt liefert. Man steigt keine Treppe, man durchquert Räume: die Innensicht einer Großorganisation (wie Tech wirklich gekauft wird), die Startup-Sicht (wie man Delivery von Grund auf baut), die Portfolio-Sicht (wie man eine Vielzahl von Kunden und Verträgen führt). Eine ‚lineare’ Karriere produziert höchstens eine Linse — nützlich, aber blind für die anderen beiden.
Was lernt man im Konzern, das von außen unsichtbar bleibt?
Dass scheinbar technische Entscheidungen es kaum sind. Man lernt die reale Dynamik der Lieferantenbeziehung — Procurement, SLA, Scope Drift, Eskalation — und wie Vertragsmacht, mehr als Features, bestimmt, was tatsächlich geliefert wird. Wissen, das ein Senior-Entwickler durch Osmose aufnimmt, nicht durch Schulungen.
Warum fügt die Startup-Phase eine unverzichtbare Linse hinzu?
Weil keine Abteilung schon weiß, wie es geht. Lieferprozesse zu definieren, Services zu bepreisen, Architektur in unbekannter Domäne von null zu bauen, dem ersten Kunden ohne Sicherheitsnetz zu antworten — das ist der Unterschied zwischen ein Handwerk kennen und es lehren können. Hier lernt man, Prozess von Theater zu unterscheiden.
Was ändert sich, wenn man ein heterogenes Portfolio führt?
Du erkennst querliegende Muster. Wenn du in derselben Woche einen Telco, einen HR-Konzern, eine Region und eine Handelskammer siehst, verstehst du, dass dieselben Sourcing-Fehler in verschiedenen Branchen wiederkehren — mit genug Varianten, um Verallgemeinerung nützlich zu machen. Die Linse, die der klassischen Advisory fehlt — sie sieht eine Branche zur Zeit, nicht das gemeinsame Muster.
Der Autor
