First Developer und das Führungsproblem
Auch wenn die Kommentarfunktion in Blogs im Allgemeinen immer weniger benutzt wird, will ich heute mal wieder versuchen ein paar Meinungen einzusammeln. Das Thema um das es sich handelt sind CTOs.
Ich war vor kurzem wieder in einer Firma, wo der CTO der erste Entwickler war. Vor 10 Jahren als erstes eingestellt, kennt er die Applikation besser als jeder andere. Den Kern hat er mitentwickelt und weiß wie die „Architektur“ läuft. Aber ist das gut?
Ich bin bei der ganzen Sache eher zwiegespalten, obwohl ich eine Tendenz Richtung „Nein, es ist nicht gut“ habe. Aber fangen wir erstmal an die positiven Aspekte aufzulisten:
- Loyalität
Wenn jemand seit Jahren im Haus ist, weiß man, dass er der Firma loyal gegenüber ist. Sicherlich hat man schon die einige höhen und Tiefen mitgemacht und ist dem Hause treu geblieben. Ist sicherlich nicht die schlimmste Eigenschaft eines CTOs, wenn er das Boot nicht verlässt, wenn es am Sinken ist. - Vertrauen
Es ist nicht nur wichtig, dass die Führung nicht abhaut, wenn es Hart auf Hart kommt, sondern auch, dass man ihr vertrauen kann. Geht zwar meist Hand in Hand mit Loyalität, aber einen kleinen Unterschied sehe ich schon. - Wissensicherung
Ich habe es bereits geschrieben, der erste Entwickler hat oft Wissen parat, das andere nicht haben. Dies zu verlieren kann kritisch für das Unternehmen sein. Beförderungen, mehr Geld und höheres Ansehen können sicher dazu beitragen eine Firma nicht so schnell zu verlassen. - Aufstiegsmotivation
„Der CTO ist einer von uns“, „wenn er es geschafft hat, dann kann ich das auch“. Es kann sehr motivierend sein, zu wissen, dass es Aufstiegschancen gibt. Auch wenn der CTO-Posten weg ist, gibt es immer noch andere Möglichkeiten.
Gut, einige positive Aspekte waren ja dabei. Negative gibt es aber leider auch:
- Konzentration auf Technik
Ich hatte das „Glück“ bisher unter zwei Chefs gearbeitet zu haben, die wegen ihres technischen Wissens befördert wurden. Einer war zwar kein CTO, aber trotzdem Abteilungsleiter. Was das Tolle an den zwei war, war dass sie jeden Abend noch mal die SVN-Commits ihrer Entwickler durchgegangen sind. Wenn ein Performance-Problem im Code drinnen war, dann haben sie den Entwickler am nächsten Tag ins Büro gerufen.
Was ich daran ganz schlimm finde, ist dass dort eine Ebene übersprungen wurden. Nicht der Teamleiter wurde angesprochen, sondern der Entwickler. Nicht der Teamleiter oder ein Kollege hat das Reveiw gemacht, sondern der CTO. Es war irgendwie ein Gefühl der ständigen Überwachung und das war nicht gut. - Führungsmängel
Wer befördert wird, weil er ein guter Techniker ist, muss nicht unbedingt Führungsstärke haben. Meine Chefs hatten sie nicht. Leider. Wie man Menschen motiviert war ihnen fremd. Wie man Termine moderiert auch. Wie man strukturiert arbeitet wussten sie oft auch nicht. Dummerweise konnte man da also auch nichts von ihnen lernen. - Strategie
Wenn man sich den ganzen Tag um Mikrooptimierung und Technik kümmert, hat man keine Chance sich um die Strategie des Unternehmens zu kümmern. Meistens werden also nur kleine Veränderungen vorangetrieben und man hat keine klare Vision, wo man eines Tages hin will. Der Status Quo ist ihnen wichtig. - Vielfalt
Es muss nicht schlimm sein, einen technischen Hintergrund zu haben. Ganz im Gegenteil. Wenn man aber zu lange bei einer Firma ist, dann hat man die Welt da draußen noch nicht gesehen. Wie machen es die anderen? Was bedeutet es ein guter Chef zu sein? Wie ist es mit richtig guten Leuten zu arbeiten? Wie bin ich im Vergleich zu anderen? Dies können sie oft nicht beantworten.
Ich hatte also bisher schlechte Erfahrungen mit Chefs gemacht, die schon lange in einer Firma waren und deswegen aufgestiegen sind. Das kann ich sagen, weil ich auch eine Welt gesehen habe, in der es anders läuft.
Meiner Meinung nach hat ein guter Chef schon viele Stationen in seinem Leben besetzt und kennt die Aufgaben seiner Mitarbeiter. Er hat technisches Wissen, das ausreicht, um zu entscheiden ob es sinnvoll ist, was seine Leuten machen oder nicht. Er weiß, was seine Mitarbeiter brauchen, um besonders effektiv arbeiten zu können und vertraut ihnen, ohne jeden Abend das SVN anzuwerfen.
Wie seht ihr das? Gute Erfahrungen mir einem solchen Chef gemacht? Habt ihr besondere Anforderungen an eine Führungsperson?
Ich glaube ich hätte das Peter-Prinzip noch erwähnen sollen. Aber egal.
Hi!
Sehe das ganz ähnlich wie du. Es ist leider ein Problem, dass Leute an der Karriereleiter noch oben steigen, die es besser nicht getan hätten. Sie waren/sind super in dem was sie vorher gemacht haben, technisch auf der Höhe und aufgrund ihrer guten Arbeit finden sie sich auf einmal in Positionen wieder, die eben nicht mehr ihren Stärken entsprechen. Auf einmal geht es eben um Arbeitsorganisation, Abstimmung, Mitarbeitermotivation, das große Ganze. Und das schlimmste ist, dass man damit oft leider eben die Mitarbeiter trifft, die „unter“ dem nun neuen Chef arbeiten müssen.
Andererseits ist es eben wichtig, trotzdem diese Aufstiegschancen zu haben, was ein große Motivation sein kann. Das entscheidende wird wohl oft der/die Chefs sein, die entscheiden müssen wen man aus welchen Gründen auf neue Positionen setz und wen besser nicht. Damit tritt man dann natürlich dem ein oder anderen auf die Füße und muss harte Entscheidungen treffen.
Ich sehe etwas anders. Die eigentlichen Probleme hast du ja auch bereits genannt. CTO zu sein nur weil man schon lange dabei ist, ist eine schlechte Begründung und Grundlage um einen solchen Posten zu besetzten.
Weiterhin ist es nicht Aufgabe des CTOs am Feierabend nochmal durchs SVN/GIT zu gehen um seine Mitarbeiten zu „überprüfen“.
Stattdessen sollte er sich eben um die Strategie, Motivieren, Delegieren usw. kümmern. Ich finde es sehr gut, wenn der CTO sich auf dem laufenden hält und dazu durchs SVN/GIT geht. Noch besser wenn dieser bei den Reviews dabei ist, sodass seine Mitarbeiter von seiner Erfahrung profitieren kann. Wichtig hierbei ist dann einfach, dass Rang und Name vor der Tür bleiben. Er ist dann eben einer von vielen und nicht der CTO.
Das eigentlich schöne an einem solchen CTO ist, dass man ihm in der Regeln die Vor- oder Nachteile, von Techniken usw. nicht erst erklären muss oder schlimmer noch darum betteln muss diese Einsetzten zu dürfen. Ich denke da immer an die Zeile aus dem Buch von Steve Jobs, in der Steve seinem Entwickler beschuldigt, dass alles was nicht funktionieren würde oder schlecht laufen würde, die Schuld seines Entwicklers gewesen sei. Dieser Antwortete darauf: „Das vielmehr alles was funktionieren würde, und gut laufen würde, seine Schuld sei und das er darum betteln musste die Funktionalitäten einbauen zu dürfen“.
Moin,
ich denke der Hund liegt woanders begraben.
Wenn der CTO von seinen bisherigen Aufgaben nicht los lassen kann ist das ein Problem. Dann muss ihm das klar gemacht werden, dass es nicht mehr zu seiner Job Description gehört. Das kann man ihm also austreiben. Und will er das nicht loslassen darf auch mal ein CTO vom CEO angezählt werden. Das führt uns aber zum eigentlichen Problem:
Die Gefahr , die ich immer wieder erlebe ist die Verweildauer im Unternehmen. Die Loyalität des Unternehmens zum CTO. Er ist unantastbar. Er hat ein Netzwerk welches für jeden gefährlich wird der anderer Meinung ist. Das heißt der technologische Fortschritt einer Firma ist ausschließlich von ihm abhängig. Was ja auch irgendwo seiner Aufgabe ist. Hast Du da aber Jemanden sitzen, der eben immer noch selbst ins SVN guckt und alles gemacht wird wie er das geil findet, dann wirst Du ihn nicht mehr los und das arbeiten wird zur Qual und die ganze Firma leidet.
Lösung:
– Bereite jeden Mitarbeiter in jeder Entwicklungsstufe auf seine neuen Aufgaben vor und entziehe bewusst alte Aufgaben und verteile sie neu.
– Schule den Mitarbeiter in Führung, Feedback und Prinzipien
– Betreibe eine echte Feedback Kultur, die es erlaubt kritisch zu sein ohne den Kopf dafür zu verlieren (Bote wird geköpft)
– Scheue Dich nicht die neue Führungsperson bei nicht erwünschtem Verhalten zu ermahnen
– Enable deine Fachkräfte Entscheidungen zu treffen, die fachlicher Natur sind und bilde einen Rat der Weisen (Der CTO gibt Rahmenbedingungen vor und der Rat bietet Lösungen an. Der CTO entscheidet nur welche der angebotenen Lösungen umgesetzt wird, keine andere)
und eine sehr elegante Lösung:
– Die Fachkräfte entscheiden wer eine Beförderung verdient
just my thoughts 🙂
Frank
Ha.. gutes Thema..
Ich persönlich denke dass es immer eine Einstellungssache bzw. eine Frage der Persönlichkeit selbst ist. Führungsqualitäten kommen nicht von fachlichen Qualitäten. Umgekehrt aber auch nicht.
Ein CTO muss mehr drauf haben als nur die Technik.
Und da sind wir schon bei des Pudels Kern.
Jemanden nur wegen seiner fachlichen Qualifikation zum CTO zu machen halte ich für gefährlich.
Ich erlebe oder höre immer wieder solche Geschichten.
Selbst erlebt habe ich einen CTO/Geschäftsführer der irgendwann Anfang der 2000er stehen geblieben ist und eine Sourcecodeverwaltung für neumodischen Kram gehalten hat.
Das ist natürlich das andere Extrem.
Ich denke dass der Mittelweg oder die Mehrfachqualifikation aus Führungsqualitäten und fachlicher Kompetenz die richtige Mischung ist die gefunden werden muss.
C;M
Ich stimme Dir zu. Der Punkt ist aus meiner Sicht auch, dass man zwar seine Führungsqualitäten durch den Besuch von Seminaren und Workshops verbessern kann, aber dennoch immer „geborenen“ Führungspersönlichkeiten hinterher bleibt. Feingefühl, 7.Sinn und dergleichen liegen vor allem in der Persönlichkeit, also im Charakter, aber auch in Erziehung und Erfahrung. Als Freelancer habe ich haufenweise CTO und Heads, aber auch TeamLeads erlebt, die diesen Softskills ermangelten.
Dabei wird gerade in Deutschland noch sehr viel Wert auf Abschlüsse und Zertifikate gelegt. Oft gilt ein Diplom oder Master schon als Zugangsgarant für höhere Posten. Dabei sind es nicht selten die Querdenker und -einsteiger, die wissen, wie man Leute motiviert, weil sie sich selbst einst dazu motivierten, einen neuen Weg einzuschlagen. Oder auch Nerds, die zwar keinerlei Abschluss vorweisen können, aber in dem was sie tun, Experten sind.
Grundsätzlich denke ich, dass es vom Unternehmen abhängt, mit wem der CTO-Posten besetzt werden sollte. In großen Unternehmen (500+ Mitarbeiter) bekommt man so gut wie nie den CTO zu Gesicht. Bestenfalls grüßt man sich auf dem Flur oder spricht mit dessen Sekretärin. Ob der nun Softskills hat oder nicht, wird außer den anderen C’s und Heads kaum jemand bemerken. In kleinen StartUps hingegen sitzt der CTO oft mit bei den Entwicklern im (Großraum-) Büro. Hier sind meiner Ansicht nach SoftSkills viel wichtiger als das technische Verständnis. Das fängt mit dem Respekt an, den jeder Entwickler verdient hat (vom Praktikanten über Juniors bis hin zu Seniors und Leads) und endet bei der Fähigkeit, aus jedem noch so schlimmen Haufen ein Team machen zu können.
Aber vor allem ändert sich, wie Du auch schon geschrieben hast, das Tätigkeitsfeld beinahe grundlegend, wenn jemand vom Entwickler zum CTO oder Head wird. Ein CTO ist vor allem ein Manager mit Entwickler-Background und kein Entwickler mit zusätzlichen Managementaufgaben. Das sollte jedem klar werden, der diesen Posten bekleidet. Selbst wer alle Design-Pattern chinesisch rückwärts herunter beten und richtig anwenden kann, wer für jedes technische Problem immer eine gute oder gar die beste Lösung findet und die Sourcen durchdrungen hat wie kein anderer, kann als CTO trotzdem jämmerlich versagen. Denn diese Fähigkeiten sind jetzt nur noch ein Nice-To-Have und keine Voraussetzung mehr. Im Gegenteil habe ich sogar schon einen CTO kennengelernt, der nicht einmal einen technischen Background hatte, dafür aber ein Genie in Organisation und Menschenführung war. Der hatte sich eben aus seinem Entwicklerteam die Seniors zu technischen Fragen heran gezogen und hat auch sehr schnell bemerkt, wessen Meinung wieviel wog. Insgesamt lief es dort sehr harmonisch ab, was ein gutes Klima zur Folge hatte, was dann in Spaß bei der Arbeit resultierte und letztlich auch der Produktivität zugute kam.
Und Du hast auch recht, dass vor allem die „Dienstältesten“ in bestimmte Positionen geschoben werden, statt demjenigen, der einen Posten am Besten auskleiden würde. Oft wird es als „Anerkennung der bisherigen Leistung“ gemacht. Manchmal aber auch, weil man das technische Verständnis überbewertet oder weil man schlicht keinen anderen findet, den man den Posten am ehesten zutrauen würde. Oder, und das scheint mir auch gar nicht selten zu passieren, versucht man, an der falschen Stelle zu sparen. Einen guten CTO auf dem Markt zu finden, kostet einen Haufen Geld. Meist ist es billiger, den Chefentwickler einfach zu befördern, ihm 10% mehr Gehalt zu geben und dann mal wursteln zu lassen, statt eine erfahrene Kapazität zu holen, die schon von Anfang an ein Vielfaches kostet und dann nur über einen HeadHunter zu bekommen ist. Ich will damit gar nicht sagen, dass ein Entwickler grundsätzlich nicht zum CTO oder zum Manager taugt. Aber das Kriterium darf nicht sein, wie gut der Entwickler in seinem derzeitigen Job ist. Denn das sagt nur aus, dass er derzeit goldrichtig besetzt ist, nicht aber, dass er es in Zukunft auch sein wird.
Unter dem Strich habe ich etwa genauso viele gute, wie auch schlechte CTOs erlebt. Die Palette ist bunt; von „katastrophal“ bis „fantastisch“ war bereits alles dabei. Leider bekommt man als Angestellter von den Fähigkeiten seines zukünftigen Chefs kaum einen aussagekräftigen Eindruck beim Vorstellungsgespräch. Da ist es wohl mehr ein Überraschungsei, was sich in den ersten Wochen der Probezeit entpellt. Als Freelancer bestaunt oder belächelt man die Zustände in einer Firma ohnehin mehr von außen und auch beim schlechtesten Klima in einer Firma weiß man, dass man hier nur temporär sein wird und macht sich an diesen Firmennamen eine dicke Notiz mit Blut geschrieben: Hier nie wieder! Aber manchmal bedauert man auch, dass man nur für ein Projekt gebucht war und wäre gern geblieben.
Programmierer, die aus ihrem Fachbereich heraus befördert werden, müssen sich neue Skills anlernen.
Sie müssen Enabler werden. Lernen, andere Menschen zu fördern und zu Dingen zu befähigen. Sie müssen vor allem Steine aus dem Weg räumen und dafür sorgen, dass die eigentliche Maschine gut geschmiert läuft.
Ich bin Mitgründer und habe die Rolle des CTO bei uns (Social Media Agentur) und bin mir voll bewusst, dass ich nicht der allerbeste Programmierer des Entwicklungsteams bin.
Viel wichtiger ist es doch, dass man dafür sorgt, dass eben diese allerbesten Programmierer auch die Umgebung haben, in der sie am produktivsten sein können.
Das man ihnen Sparring bietet.
Sie nicht vor vollendete Dinge setzt.
Sie weiterentwickelt.
Selbst mehr konzeptionell denkt.
Und das man Mediator/Übersetzter zu anderen Unternehmensteilen ist (Strategie / Redaktion bei uns).