Ziehen Sie Lehren aus den Karrierefehlern unseres Autors.Anton Vierietin | shutterstock.com Im Jahr 2010 war ich als Chefentwickler bei einer ehemaligen Silicon-Valley-Größe tätig – die sich zu diesem Zeitpunkt bereits auf dem absteigenden Ast befand. Ebenso wie ihr Produkt, ein Tool, um Software zu entwickeln. Das Dev-Team, das ich in meiner Position managen durfte, war allerdings ein ausgesprochen talentiertes – und auch das Management-Team war ein umgänglicher Haufen. Ich habe den Job gemocht. Das Produkt war monolithisch – eine einzige große Installation, die am Stück erstellt und bereitgestellt werden musste. Ausgeliefert wurde einmal im Jahr. Das Development war darauf ausgerichtet, zwischen den Releases neue Funktionen zu entwickeln und Bugs zu beheben. Weil es dabei um ein Dev-Tool ging, bestand dieses aus diversen komplexen Komponenten, darunter ein Compiler, eine Runtime-Bibliothek, ein Visual Framework und eine IDE. Um das Produkt weiterhin marktrelevant zu halten, war es vor allem nötig, dieses auf neue Plattformen zu portieren. Was aufgrund der Komponenten alles andere als eine simple Aufgabenstellung war. Aber unsere Entwicklungs- und QA-Teams waren sich der damit verbundenen Aufwände stets bewusst und erfahren genug, um genau zu wissen, wie sie diese Projekte zielführend umsetzen können. Dann wurde das Unternehmen von einer anderen Firma übernommen – einem kleineren Anbieter von Datenbank-Tools. Mit dem neuen Eigentümer wurde auch ein neues Leadership-Team eingesetzt – wie das eben so üblich ist. Wir taten unser Bestes, um uns in die neue Ordnung zu integrieren, beziehungsweise integriert zu werden. Der Anfang vom Ende Obwohl Datenbank- und allgemeiner ausgerichtete Dev-Tools Schnittmengen aufweisen, war unser Produkt komplexer und auf einer tieferen Ebene angesiedelt als das unserer neuen Muttergesellschaft. Diese Diskrepanz wurde bei den Integrationsbemühungen zur Herausforderung, denn die unserem Produkt zugrundeliegenden Komponenten waren um ein Vielfaches komplexer als ein SQL-Parser und -Editor. Dem neuen Leadership-Team leuchtete das leider nicht wirklich ein. Nachdem sie zur Entscheidung gekommen waren, dass wir unser Tool sowohl auf Linux als auch auf MacOS portieren sollten, habe ich mich mit meinem Team beraten und die Anforderungen studiert. Unter dem Strich stand eine Aufwandsschätzung (ich weiß…) von circa 18 Monaten pro Migration. Natürlich haben wir auch Vorschläge erarbeitet, um diesen Zeitraum potenziell zu verkürzen – zum Beispiel indem Projekte verschoben und mehr Personal eingestellt wird (das Brooks’sche Gesetz natürlich stets im Hinterkopf). Das kam bei der neuen Führung nicht gut an. Sie waren schockiert von der Vorstellung, dass es drei Jahre dauern sollte, um die beiden neuen Plattformen zu erschließen. Ihre Schlussfolgerung: Das Team will nur auf Zeit spielen und übertreibt mit Blick auf den Aufwand maßlos, weil es eigentlich keine Lust auf Arbeit hat. Die Konsequenz: Eine Deadline von sechs Monaten – für beide Plattform-Migrationen. Aus meiner Sicht eine absolut absurde Forderung, die unmöglich zu erfüllen war. Das stimmte mich – gelinde gesagt – eher unzufrieden. Nicht nur, weil es sinnlose Nacht- und Wochenend-Schichten nach sich ziehen würde – vor allem die mehr oder weniger subtile Unterstellung, ich und mein Team seien unehrlich und faul, war eher schwierig zu verdauen. Also machte ich meine Position klar, versuchte meine Verärgerungen so gut wie möglich zu verbergen (hat nicht geklappt) – und protestierte, um meine Mannschaft vor einem sinnlosen Projekt zu bewahren, das von vorneherein zum Scheitern verurteilt war. Das stieß natürlich nicht auf viel Verständnis: Mein Vorgesetzter (der wie ich aus der Softwareentwicklung kam), wusste mit Sicherheit, wie unzumutbar die gesetzte Deadline war, vermittelte mir aber klipp und klar, dass wir es einfach versuchen müssten. Für mich war das der Anfang vom Ende: Ich wollte und konnte es nicht über mich bringen, mein Team anzuweisen, dieses Projekt anzugehen – bei dem schon vor dem Startschuss feststand, dass es an der Wand enden wird. Die Lehren der Selbstsabotage Also habe ich (aus heutiger Sicht) alles falsch gemacht, was man falsch machen kann: Ich beharrte auch gegenüber dem Leadership-Team auf meiner Protesthaltung und habe nicht ansatzweise versucht, mich als Teamplayer zu präsentieren. Stattdessen habe ich den Devs in meinem Team klar gesagt, dass ich den Plan der Geschäftsleitung für verrückt halte – und es keinen Sinn macht, das Projekt überhaupt anzugehen. Letztendlich kostete mich meine unreife Haltung dann meinen Job. Natürlich hatte ich in der Sache recht, aber ohne Rücksicht auf Jobverlust auf meinem Standpunkt zu verharren, war ein vermeidbarer, dummer Fehler. Stattdessen hätte ich als Entwickler mit Führungsverantwortung einen Mittelweg finden müssen, der sowohl die Ziele der Geschäftsleitung unterstützt als auch mein Team. Das wäre angesichts der Umstände natürlich eine Herausforderung – aber auch einen Versuch wert – gewesen. Die Lektion, die ich aus dieser Episode meiner Karriere gelernt habe, lässt sich auch auf Management-Positionen außerhalb der Softwareentwicklung übertragen. Eine Rolle dieser Art erfordert, einen Balanceakt zu vollziehen: Einerseits gilt es, gegenüber der Geschäftsleitung Loyalität an den Tag zu legen, andererseits die Mitarbeiter bestmöglich zu schützen, für die man Verantwortung trägt. Und: Manager sollten in der Lage sein, nicht immer Recht haben zu müssen – und das große Ganze über die eigenen Bedürfnisse zu stellen. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
So wird man einen Job als Chefentwickler los
Ziehen Sie Lehren aus den Karrierefehlern unseres Autors.Anton Vierietin | shutterstock.com Im Jahr 2010 war ich als Chefentwickler bei einer ehemaligen Silicon-Valley-Größe tätig – die sich zu diesem Zeitpunkt bereits auf dem absteigenden Ast befand. Ebenso wie ihr Produkt, ein Tool, um Software zu entwickeln. Das Dev-Team, das ich in meiner Position managen durfte, war allerdings ein ausgesprochen talentiertes – und auch das Management-Team war ein umgänglicher Haufen. Ich habe den Job gemocht. Das Produkt war monolithisch – eine einzige große Installation, die am Stück erstellt und bereitgestellt werden musste. Ausgeliefert wurde einmal im Jahr. Das Development war darauf ausgerichtet, zwischen den Releases neue Funktionen zu entwickeln und Bugs zu beheben. Weil es dabei um ein Dev-Tool ging, bestand dieses aus diversen komplexen Komponenten, darunter ein Compiler, eine Runtime-Bibliothek, ein Visual Framework und eine IDE. Um das Produkt weiterhin marktrelevant zu halten, war es vor allem nötig, dieses auf neue Plattformen zu portieren. Was aufgrund der Komponenten alles andere als eine simple Aufgabenstellung war. Aber unsere Entwicklungs- und QA-Teams waren sich der damit verbundenen Aufwände stets bewusst und erfahren genug, um genau zu wissen, wie sie diese Projekte zielführend umsetzen können. Dann wurde das Unternehmen von einer anderen Firma übernommen – einem kleineren Anbieter von Datenbank-Tools. Mit dem neuen Eigentümer wurde auch ein neues Leadership-Team eingesetzt – wie das eben so üblich ist. Wir taten unser Bestes, um uns in die neue Ordnung zu integrieren, beziehungsweise integriert zu werden. Der Anfang vom Ende Obwohl Datenbank- und allgemeiner ausgerichtete Dev-Tools Schnittmengen aufweisen, war unser Produkt komplexer und auf einer tieferen Ebene angesiedelt als das unserer neuen Muttergesellschaft. Diese Diskrepanz wurde bei den Integrationsbemühungen zur Herausforderung, denn die unserem Produkt zugrundeliegenden Komponenten waren um ein Vielfaches komplexer als ein SQL-Parser und -Editor. Dem neuen Leadership-Team leuchtete das leider nicht wirklich ein. Nachdem sie zur Entscheidung gekommen waren, dass wir unser Tool sowohl auf Linux als auch auf MacOS portieren sollten, habe ich mich mit meinem Team beraten und die Anforderungen studiert. Unter dem Strich stand eine Aufwandsschätzung (ich weiß…) von circa 18 Monaten pro Migration. Natürlich haben wir auch Vorschläge erarbeitet, um diesen Zeitraum potenziell zu verkürzen – zum Beispiel indem Projekte verschoben und mehr Personal eingestellt wird (das Brooks’sche Gesetz natürlich stets im Hinterkopf). Das kam bei der neuen Führung nicht gut an. Sie waren schockiert von der Vorstellung, dass es drei Jahre dauern sollte, um die beiden neuen Plattformen zu erschließen. Ihre Schlussfolgerung: Das Team will nur auf Zeit spielen und übertreibt mit Blick auf den Aufwand maßlos, weil es eigentlich keine Lust auf Arbeit hat. Die Konsequenz: Eine Deadline von sechs Monaten – für beide Plattform-Migrationen. Aus meiner Sicht eine absolut absurde Forderung, die unmöglich zu erfüllen war. Das stimmte mich – gelinde gesagt – eher unzufrieden. Nicht nur, weil es sinnlose Nacht- und Wochenend-Schichten nach sich ziehen würde – vor allem die mehr oder weniger subtile Unterstellung, ich und mein Team seien unehrlich und faul, war eher schwierig zu verdauen. Also machte ich meine Position klar, versuchte meine Verärgerungen so gut wie möglich zu verbergen (hat nicht geklappt) – und protestierte, um meine Mannschaft vor einem sinnlosen Projekt zu bewahren, das von vorneherein zum Scheitern verurteilt war. Das stieß natürlich nicht auf viel Verständnis: Mein Vorgesetzter (der wie ich aus der Softwareentwicklung kam), wusste mit Sicherheit, wie unzumutbar die gesetzte Deadline war, vermittelte mir aber klipp und klar, dass wir es einfach versuchen müssten. Für mich war das der Anfang vom Ende: Ich wollte und konnte es nicht über mich bringen, mein Team anzuweisen, dieses Projekt anzugehen – bei dem schon vor dem Startschuss feststand, dass es an der Wand enden wird. Die Lehren der Selbstsabotage Also habe ich (aus heutiger Sicht) alles falsch gemacht, was man falsch machen kann: Ich beharrte auch gegenüber dem Leadership-Team auf meiner Protesthaltung und habe nicht ansatzweise versucht, mich als Teamplayer zu präsentieren. Stattdessen habe ich den Devs in meinem Team klar gesagt, dass ich den Plan der Geschäftsleitung für verrückt halte – und es keinen Sinn macht, das Projekt überhaupt anzugehen. Letztendlich kostete mich meine unreife Haltung dann meinen Job. Natürlich hatte ich in der Sache recht, aber ohne Rücksicht auf Jobverlust auf meinem Standpunkt zu verharren, war ein vermeidbarer, dummer Fehler. Stattdessen hätte ich als Entwickler mit Führungsverantwortung einen Mittelweg finden müssen, der sowohl die Ziele der Geschäftsleitung unterstützt als auch mein Team. Das wäre angesichts der Umstände natürlich eine Herausforderung – aber auch einen Versuch wert – gewesen. Die Lektion, die ich aus dieser Episode meiner Karriere gelernt habe, lässt sich auch auf Management-Positionen außerhalb der Softwareentwicklung übertragen. Eine Rolle dieser Art erfordert, einen Balanceakt zu vollziehen: Einerseits gilt es, gegenüber der Geschäftsleitung Loyalität an den Tag zu legen, andererseits die Mitarbeiter bestmöglich zu schützen, für die man Verantwortung trägt. Und: Manager sollten in der Lage sein, nicht immer Recht haben zu müssen – und das große Ganze über die eigenen Bedürfnisse zu stellen. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
So wird man einen Job als Chefentwickler los Ziehen Sie Lehren aus den Karrierefehlern unseres Autors.Anton Vierietin | shutterstock.com Im Jahr 2010 war ich als Chefentwickler bei einer ehemaligen Silicon-Valley-Größe tätig – die sich zu diesem Zeitpunkt bereits auf dem absteigenden Ast befand. Ebenso wie ihr Produkt, ein Tool, um Software zu entwickeln. Das Dev-Team, das ich in meiner Position managen durfte, war allerdings ein ausgesprochen talentiertes – und auch das Management-Team war ein umgänglicher Haufen. Ich habe den Job gemocht. Das Produkt war monolithisch – eine einzige große Installation, die am Stück erstellt und bereitgestellt werden musste. Ausgeliefert wurde einmal im Jahr. Das Development war darauf ausgerichtet, zwischen den Releases neue Funktionen zu entwickeln und Bugs zu beheben. Weil es dabei um ein Dev-Tool ging, bestand dieses aus diversen komplexen Komponenten, darunter ein Compiler, eine Runtime-Bibliothek, ein Visual Framework und eine IDE. Um das Produkt weiterhin marktrelevant zu halten, war es vor allem nötig, dieses auf neue Plattformen zu portieren. Was aufgrund der Komponenten alles andere als eine simple Aufgabenstellung war. Aber unsere Entwicklungs- und QA-Teams waren sich der damit verbundenen Aufwände stets bewusst und erfahren genug, um genau zu wissen, wie sie diese Projekte zielführend umsetzen können. Dann wurde das Unternehmen von einer anderen Firma übernommen – einem kleineren Anbieter von Datenbank-Tools. Mit dem neuen Eigentümer wurde auch ein neues Leadership-Team eingesetzt – wie das eben so üblich ist. Wir taten unser Bestes, um uns in die neue Ordnung zu integrieren, beziehungsweise integriert zu werden. Der Anfang vom Ende Obwohl Datenbank- und allgemeiner ausgerichtete Dev-Tools Schnittmengen aufweisen, war unser Produkt komplexer und auf einer tieferen Ebene angesiedelt als das unserer neuen Muttergesellschaft. Diese Diskrepanz wurde bei den Integrationsbemühungen zur Herausforderung, denn die unserem Produkt zugrundeliegenden Komponenten waren um ein Vielfaches komplexer als ein SQL-Parser und -Editor. Dem neuen Leadership-Team leuchtete das leider nicht wirklich ein. Nachdem sie zur Entscheidung gekommen waren, dass wir unser Tool sowohl auf Linux als auch auf MacOS portieren sollten, habe ich mich mit meinem Team beraten und die Anforderungen studiert. Unter dem Strich stand eine Aufwandsschätzung (ich weiß…) von circa 18 Monaten pro Migration. Natürlich haben wir auch Vorschläge erarbeitet, um diesen Zeitraum potenziell zu verkürzen – zum Beispiel indem Projekte verschoben und mehr Personal eingestellt wird (das Brooks’sche Gesetz natürlich stets im Hinterkopf). Das kam bei der neuen Führung nicht gut an. Sie waren schockiert von der Vorstellung, dass es drei Jahre dauern sollte, um die beiden neuen Plattformen zu erschließen. Ihre Schlussfolgerung: Das Team will nur auf Zeit spielen und übertreibt mit Blick auf den Aufwand maßlos, weil es eigentlich keine Lust auf Arbeit hat. Die Konsequenz: Eine Deadline von sechs Monaten – für beide Plattform-Migrationen. Aus meiner Sicht eine absolut absurde Forderung, die unmöglich zu erfüllen war. Das stimmte mich – gelinde gesagt – eher unzufrieden. Nicht nur, weil es sinnlose Nacht- und Wochenend-Schichten nach sich ziehen würde – vor allem die mehr oder weniger subtile Unterstellung, ich und mein Team seien unehrlich und faul, war eher schwierig zu verdauen. Also machte ich meine Position klar, versuchte meine Verärgerungen so gut wie möglich zu verbergen (hat nicht geklappt) – und protestierte, um meine Mannschaft vor einem sinnlosen Projekt zu bewahren, das von vorneherein zum Scheitern verurteilt war. Das stieß natürlich nicht auf viel Verständnis: Mein Vorgesetzter (der wie ich aus der Softwareentwicklung kam), wusste mit Sicherheit, wie unzumutbar die gesetzte Deadline war, vermittelte mir aber klipp und klar, dass wir es einfach versuchen müssten. Für mich war das der Anfang vom Ende: Ich wollte und konnte es nicht über mich bringen, mein Team anzuweisen, dieses Projekt anzugehen – bei dem schon vor dem Startschuss feststand, dass es an der Wand enden wird. Die Lehren der Selbstsabotage Also habe ich (aus heutiger Sicht) alles falsch gemacht, was man falsch machen kann: Ich beharrte auch gegenüber dem Leadership-Team auf meiner Protesthaltung und habe nicht ansatzweise versucht, mich als Teamplayer zu präsentieren. Stattdessen habe ich den Devs in meinem Team klar gesagt, dass ich den Plan der Geschäftsleitung für verrückt halte – und es keinen Sinn macht, das Projekt überhaupt anzugehen. Letztendlich kostete mich meine unreife Haltung dann meinen Job. Natürlich hatte ich in der Sache recht, aber ohne Rücksicht auf Jobverlust auf meinem Standpunkt zu verharren, war ein vermeidbarer, dummer Fehler. Stattdessen hätte ich als Entwickler mit Führungsverantwortung einen Mittelweg finden müssen, der sowohl die Ziele der Geschäftsleitung unterstützt als auch mein Team. Das wäre angesichts der Umstände natürlich eine Herausforderung – aber auch einen Versuch wert – gewesen. Die Lektion, die ich aus dieser Episode meiner Karriere gelernt habe, lässt sich auch auf Management-Positionen außerhalb der Softwareentwicklung übertragen. Eine Rolle dieser Art erfordert, einen Balanceakt zu vollziehen: Einerseits gilt es, gegenüber der Geschäftsleitung Loyalität an den Tag zu legen, andererseits die Mitarbeiter bestmöglich zu schützen, für die man Verantwortung trägt. Und: Manager sollten in der Lage sein, nicht immer Recht haben zu müssen – und das große Ganze über die eigenen Bedürfnisse zu stellen. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!