Genau an dem Tag, als ich meine neue Stelle als Leiter Software-Entwicklung in einem Großunternehmen antrat, musste dessen Vorstand den größten Verlust der Firmengeschichte eingestehen. Es gab rigide Sparmaßnahmen und alle Abteilungen standen unter dem Druck, ihre Effizienz zu erhöhen. Mein Vertrag war zum Glück kurz vor dem Einstellungsstopp abgeschlossen worden, aber mir war bewusst: Als Führungskraft werde ich daran gemessen, wie viel ich zur Erhöhung der Rentabilität beitrage.

Meine Aufgabe war es, mehrere Teams mit insgesamt 15 Entwicklern zu führen. Es gab nur interne Kunden, Auftraggeber waren in der Regel die Fachabteilungen. Meine Teams leisteten neben Entwicklungsprojekten den Third-Level-Support. Dies bedeutet, dass sie Software-Probleme lösten, die z.T. Fehlerbehebungen in der Software erforderten.

Bei der Einführung schilderte mein unmittelbarer Vorgesetzter diese Teams als sehr leistungsfähig und kundenorientiert. Außerdem lobte er die bestehende Teamkultur.

Ich nahm Kontakt mit den Kunden und anderen Teamleitern auf, die mit meinen Teams zusammenarbeiteten. Ich wollte mehr Details über meine Stelle, die Erwartungshaltungen an mich und die Teams erhalten. Vom Teamleiter des First- und Second-Level-Supports erhielt ich Informationen zur Anzahl der Tickets in der Produktion. Die anderen Teamleiter gaben mir ihre Ressourcenschätzungen für das laufende Jahr, die aktuellen Projekte und die sonstigen Aufgaben.

Dabei fiel mir bei einem meiner Teams – nennen wir es Team Delta – auf, dass es im Vergleich zu den anderen Teams hohe Aufwände im Bereich Maintenance und Support hatte. Die Aufwände für den Third-Level-Support betrugen bei diesem Team mehr als 20% der Arbeitskapazität. Meine Entwickler verbrachten also ein Fünftel und mehr ihrer Zeit damit, Fehler zu suchen und ggf. zu beheben und konnten somit nicht an neuen Funktionalitäten arbeiten.

Im Vergleich mit anderer Anwendungs-Software in diesem Unternehmen war dies zwar kein besonders hoher Wert, aber aus meiner Sicht und meiner Erfahrung in vergleichbaren Umfeldern empfand ich die Anzahl der Tickets und den Aufwand für deren Erledigung als zu hoch.

Mit dieser Einschätzung stand ich allerdings alleine da. Es sah so aus, als gäbe es niemanden, der die Leistungsfähigkeit der Abteilung verbessern wollte, um so einen Mehrwert für das Unternehmen zu schaffen. Die internen Kunden, mein Chef und das Team hatten sich offensichtlich mit der hohen Anzahl an Fehlern und der damit verbundenen zeitlichen Aufwände abgefunden. Time-to-Market, d.h. ein Produkt zum vereinbarten Termin auf Biegen und Brechen zu liefern, erschien allen wichtiger als eine annähernd fehlerfreie Funktionalität. Dementsprechend war der Teamleiter davon überzeugt, ein sehr gutes, lieferfähiges Team zu haben. Dass der Kunde dabei die Rolle des Alphatesters innehatte, war akzeptiert.

Im Gegensatz zur herrschenden Einstellung wollte ich hohe Qualität mit wenigen Fehlern erreichen. Mein Ziel war, mehr neue Funktionalität liefern zu können und Patchdeployments, d.h. Auslieferungen nur zur Fehlerbehebung, weitgehend zu vermeiden. Nur so schien es mir möglich, die Effizienz meiner Teams zu erhöhen, also mit denselben Ressourcen zu denselben Kosten mehr zu liefern.

Um die Situation besser zu verstehen und meine Einschätzung zu überprüfen, beobachtete ich in den ersten drei Monaten die Teams und ihre Arbeitsweise sorgfältig. Da wir in einem Großraumbüro arbeiteten, konnte ich leicht sehen, wie die Teams miteinander umgehen. Dabei stellte ich fest, dass das Team Delta nicht sehr kommunikativ war. Es gab kaum Teambesprechungen, alle saßen vor ihren Rechnern und programmierten und sprachen über den Tag verteilt wenig miteinander. Auch zum Mittagessen oder zum Kaffee gingen die Teammitglieder nicht gemeinsam.

Um zu verstehen, was der Kunde verlangt, was die Teamleiter und Teams leisten und wie sie mit der Situation umgehen, nahm ich als schweigender Zuhörer an vielen Besprechungen teil. Dabei stellte ich fest, dass die Abläufe beim Team Delta, das schon seit Jahren in dieser Konstellation zusammenarbeitete, gut eingespielt waren. Das Team war tatsächlich sehr kundenorientiert – allerdings in einer sehr kurzfristigen Perspektive: Es war üblich, dass der Kunde direkt Kontakt mit den Entwicklern aufnahm und diese dann die Kundenanforderungen unmittelbar am produktiven System umsetzten.