1. Foren
  2. Kommentare
  3. Wirtschaft-Forum
  4. Alle Kommentare zum Artikel
  5. › Weiterbildung: Was IT…

Nein, die müssen nicht "coden" können.

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema Ansicht wechseln


  1. Nein, die müssen nicht "coden" können.

    Autor: SchluppoMäcQuarkkeulchen 17.11.20 - 09:21

    Ich bin als Führungskraft komplett quer in die IT gekommen. Bei einem stark wachsenden Unternehmen, welches damals seine Führungskräfte aus dem Bestand der Entwickler rekrutiert hat. Im Ergebnis waren alle Teamleiter/Manager halb Entwickler/halb Leitung. Hat viele Vorteile weil natürlich ein großes Verständnis für die tägliche Arbeit da ist, klar.
    Meine Erfahrung war aber auch, dass Führung eben vor allem Mitarbeiterentwicklung, Weiterbildung, Personalgespräche, Strategie usw. usw. ausmacht, was die frisch beförderten Entwickler so noch nicht drauf hatten bzw. ihnen auch niemand beibringen konnte in der Firma, weil alle anderen eben auch Ex-Entwickler waren.
    Ich kann bis heute nicht "coden", auch wenn ich inzwischen natürlich mehr Verständnis/Wissen für die IT habe. Damit die Teams gut vorankommen, motiviert bleiben, die Fluktuation niedrig bleibt, sich jeder gut entwickeln kann, muss eine Führungskraft (meine Meinung) aber nicht coden können oder zwangsläufig aus dem Bereich heraus aufgestiegen sein.

  2. Re: Nein, die müssen nicht "coden" können.

    Autor: Kaiser Ming 17.11.20 - 09:30

    SchluppoMäcQuarkkeulchen schrieb:
    --------------------------------------------------------------------------------
    > Ich bin als Führungskraft komplett quer in die IT gekommen. Bei einem stark
    > wachsenden Unternehmen, welches damals seine Führungskräfte aus dem Bestand
    > der Entwickler rekrutiert hat. Im Ergebnis waren alle Teamleiter/Manager
    > halb Entwickler/halb Leitung. Hat viele Vorteile weil natürlich ein großes
    > Verständnis für die tägliche Arbeit da ist, klar.
    > Meine Erfahrung war aber auch, dass Führung eben vor allem
    > Mitarbeiterentwicklung, Weiterbildung, Personalgespräche, Strategie usw.
    > usw. ausmacht, was die frisch beförderten Entwickler so noch nicht drauf
    > hatten bzw. ihnen auch niemand beibringen konnte in der Firma, weil alle
    > anderen eben auch Ex-Entwickler waren.
    > Ich kann bis heute nicht "coden", auch wenn ich inzwischen natürlich mehr
    > Verständnis/Wissen für die IT habe. Damit die Teams gut vorankommen,
    > motiviert bleiben, die Fluktuation niedrig bleibt, sich jeder gut
    > entwickeln kann, muss eine Führungskraft (meine Meinung) aber nicht coden
    > können oder zwangsläufig aus dem Bereich heraus aufgestiegen sein.

    Zwangsläufig nicht aber helfen tuts.
    Die Sache ist du weisst halt nicht welche Fehler du selbst evtl gemacht hast, die du anderweitig nicht gemacht hättest. Insofern ist eine Selbsteinschätzung an der Stelle zu subjektiv. ;)

  3. Re: Nein, die müssen nicht "coden" können.

    Autor: Trollversteher 17.11.20 - 09:41

    >Zwangsläufig nicht aber helfen tuts.
    >Die Sache ist du weisst halt nicht welche Fehler du selbst evtl gemacht hast, die du anderweitig >nicht gemacht hättest. Insofern ist eine Selbsteinschätzung an der Stelle zu subjektiv. ;)

    Ich, als Senior-Developer, der schon "unter" vielen Projekt/Abteilungsleitern gearbeitet htat, kann seine Selbsteinschätzung dabei nur bestätigen. Ich habe es sogar auch schon erlebt, dass "codende" Projektleiter eher von Nachteil waren, besonders wenn die Zeit des aktiven täglichen Codens schon ne Weile zurück lag, und die Betreffenden trotzdem der Meinung waren, den Entwicklern bis auf Codeebene in ihre Arbeit reinreden, oder gar selber neben bei noch ein wenig selbst am code herumfriggeln zu müssen.

    Da ist mir ein Projektleiter, der *seinen* Job versteht und gerade genug Grundkenntnisse hat um mit ihm über Problematiken auf "high level" Ebene zu diskutieren, sehr viel lieber als ein Ex-Coder, der den "guten alten Zeiten" nachtrauert und sich immer noch für ein Programmierergenie hält, obwohl er die Entwicklungen der letzten zehn Jahre nur vom Überfliegen von Artikeln auf IT Newsseiten kennt.

  4. Re: Nein, die müssen nicht "coden" können.

    Autor: Fleischgott 17.11.20 - 09:45

    Finde schon, dass eine IT-Führungskraft die Grundlagen der Programmierung beherrschen sollte. Wenn der nicht mal weiß was ein Objekt oder eine Methode ist, wird es schwer im wöchentlichen Jour Fix die Themen richtig zu diskutieren. Aber die Realität sieht leider oft anders aus...

  5. Re: Nein, die müssen nicht "coden" können.

    Autor: Trollversteher 17.11.20 - 09:50

    >Finde schon, dass eine IT-Führungskraft die Grundlagen der Programmierung beherrschen sollte. >Wenn der nicht mal weiß was ein Objekt oder eine Methode ist, wird es schwer im wöchentlichen >Jour Fix die Themen richtig zu diskutieren. Aber die Realität sieht leider oft anders aus...

    Wenn eine IT-Führungskraft die Grundlagen der Programmierung beherrschen muss, um mit den Entwicklern bis auf Objekt-Ebene zu diskutieren, dann ist imho etwas grundlegend in der Projektorganisation schief gelaufen. Für rein technische Detailfragen sollte einer der Senior Developer den Hut des "technischen Lead" aufbekommen, und mit dem kann man dann die Themen auf code/low level Basis diskutieren - aber ein Projektleiter sollte sich nicht auf dieser tiefen Ebene mit dem Projekt beschäftigen müssen, sondern sich um die allgemeine Projektorganisation kümmern und ggf. im agilen Projekt die project owner Rolle übernehmen.

  6. Re: Nein, die müssen nicht "coden" können.

    Autor: Michael H. 17.11.20 - 11:10

    Trollversteher schrieb:
    --------------------------------------------------------------------------------
    > Wenn eine IT-Führungskraft die Grundlagen der Programmierung beherrschen
    > muss, um mit den Entwicklern bis auf Objekt-Ebene zu diskutieren, dann ist
    > imho etwas grundlegend in der Projektorganisation schief gelaufen. Für rein
    > technische Detailfragen sollte einer der Senior Developer den Hut des
    > "technischen Lead" aufbekommen, und mit dem kann man dann die Themen auf
    > code/low level Basis diskutieren - aber ein Projektleiter sollte sich nicht
    > auf dieser tiefen Ebene mit dem Projekt beschäftigen müssen, sondern sich
    > um die allgemeine Projektorganisation kümmern und ggf. im agilen Projekt
    > die project owner Rolle übernehmen.

    Mir hat einer meiner ehemaligen Chefs mal gesagt, und das zitiere ich immer gerne wieder, dass man sich die Fähigkeit aneignen sollte, auch mal einen Schritt zurück machen zu können um das gesamte Bild zu sehen.

    Genauer meinte er damit, dass Leute wie wir (damit meinte er Menschen mit ausgeprägtem analytischem Denken) und dazu zähle ich vor allem auch "Coder" sich gerne in Details verrennen.

    Heisst in dem Fall, hätte ich einen PL, der selbst Coder war/ist und der würde bei jedem Fitzelchen Code mitmischen oder seinen Senf dazu geben.. ja dann würde ich behaupten, dass er ungeeignet ist für den Posten.

    Denn hier bietet es sich natürlich an, komplexe Prozesse zu verstehen und vor allem, Problematiken zu verstehen um die Zeit im Blick zu haben. Also zu wissen, was Problematik X für Auswirkungen auf den Zeitplan haben kann etc. oder wie lange es dauert dieses und jenes zu implementieren. Da können PL´s ohne den Background nicht mithalten und kommen oft mit ziemlich realitätsfremden Einschätzungen wie "bis Übermorgen sollte das fertig sein oder?", während man hier 3-4 Wochen veranschlagen könnte.

    Der kann dann nen Schritt zurück machen und behält das große Ganze im Überblick. Also Abteilung 1-3 machen den Bereich, liegen im Zeitplan, Abteilung 4 hinkt hinterher, aber in Abteilung 5 und 6 ist noch viel Luft, da kann ich 1-2 Mann abziehen. etc etc etc.

    Ich denke wenn man Code bis auf eine gewisse Ebene versteht, kriegt man ein wesentlich besseres Gefühl für die Auslastung der Leute und die Rahmenbedingungen bei bestimmten Problemen und kann besser mit seinen Leuten kommunizieren.

    Probleme auf Codelevel zu besprechen gehört da tatsächlich nicht dazu.

  7. Re: Nein, die müssen nicht "coden" können.

    Autor: scrumdideldu 17.11.20 - 10:12

    Fleischgott schrieb:
    --------------------------------------------------------------------------------
    > Finde schon, dass eine IT-Führungskraft die Grundlagen der Programmierung
    > beherrschen sollte. Wenn der nicht mal weiß was ein Objekt oder eine
    > Methode ist, wird es schwer im wöchentlichen Jour Fix die Themen richtig zu
    > diskutieren. Aber die Realität sieht leider oft anders aus...

    Wenn Ihr in einem JourFix über Methoden und Objekte redet dann ist doch was grundlegend schief oder?

  8. Re: Nein, die müssen nicht "coden" können.

    Autor: narfomat 17.11.20 - 10:14

    >Finde schon, dass eine IT-Führungskraft die Grundlagen der Programmierung beherrschen sollte.

    wieso... eine it fuehrungskraft kann ALLE MOEGLICHEN ABTEILUNGEN UND PROZESSE leiten, die wenigsten haben UEBERHAUPT mit programmierung zu tun...

    wen interessiert ob der leiter IT helpdesk services programmieren kann... oder der leiter IT datacenter tech. oder der leiter IT infrastructure/networks. wuerde nichts zu seiner aufgabe beitragen...

  9. Re: Nein, die müssen nicht "coden" können.

    Autor: gaym0r 17.11.20 - 10:23

    narfomat schrieb:
    --------------------------------------------------------------------------------
    > >Finde schon, dass eine IT-Führungskraft die Grundlagen der Programmierung
    > beherrschen sollte.
    >
    > wieso... eine it fuehrungskraft kann ALLE MOEGLICHEN ABTEILUNGEN UND
    > PROZESSE leiten, die wenigsten haben UEBERHAUPT mit programmierung zu
    > tun...

    Ist so ein golem ding. Für die meisten hier ist IT = Softwareentwicklung

  10. Re: Nein, die müssen nicht "coden" können.

    Autor: Oktavian 17.11.20 - 10:26

    > Ist so ein golem ding. Für die meisten hier ist IT = Softwareentwicklung

    Und ich dachte immer, für die meisten hier ist IT = Linux-Administration.

    Wenn aber beides gleichzeitig zutrifft, dann ist ja Softwareentwicklung = Linux-Administration. Und dann wird es absurd.

  11. Re: Nein, die müssen nicht "coden" können.

    Autor: Trollversteher 17.11.20 - 10:30

    >Und ich dachte immer, für die meisten hier ist IT = Linux-Administration.

    >Wenn aber beides gleichzeitig zutrifft, dann ist ja Softwareentwicklung = Linux-Administration. Und dann wird es absurd.

    Vielleicht einigen wir uns darauf, dass bei solchen Diskussionen hier im Forum schon mal gerne Repräsentanten eines IT Teilbereichs als repräsentativ für die gesamte Branche sehen ;-)

  12. Re: Nein, die müssen nicht "coden" können.

    Autor: Trollversteher 17.11.20 - 10:27

    >Ist so ein golem ding. Für die meisten hier ist IT = Softwareentwicklung

    Stimmt schon - außer bei Gehaltsvergleichen, da werden von Admins gerne mal generelle IT Durchschnittsgehälter angezweifelt, weil die Senior Entwickler, Projektleiter und Consultants den Durchschnitt über das im Administrationsbereich übliche Gehalt heben ;-)

  13. Re: Nein, die müssen nicht "coden" können.

    Autor: Oktavian 17.11.20 - 10:53

    > Stimmt schon - außer bei Gehaltsvergleichen, da werden von Admins gerne mal
    > generelle IT Durchschnittsgehälter angezweifelt, weil die Senior
    > Entwickler, Projektleiter und Consultants den Durchschnitt über das im
    > Administrationsbereich übliche Gehalt heben ;-)

    Du bist böse. Aber da, stimmt schon, ich amüsiere mich da auch immer kräftig.

    Da ist jemand Turnschuh-Admin bei einer 20-Mann-Butze in der Uckermark ("junges dynamische Startup im Berliner Umland") und bezweifelt, dass der Senior-SAP-Berater oder der Senior-Programmleiter auch mal das Dreifache seines Gehalts bekommt. Von einem Management-Consultant, der halt irgendwie im weiteren Sinne auch zur IT gehört, wollen wir gar nicht reden. Keine Ahnung, ob das in allen Fällen gerechtfertigt ist, aber den Tatsachen muss man schon ins Auge blicken.

    Und dass auch der Admin in einem Unternehmen mit Metaller- oder Chemie-Tarifvertrag und zusätzlichem Haustarifvertrag gerne mal das Doppelte bekommt, da langt schon ein Blick in die Tabellen.

  14. Re: Nein, die müssen nicht "coden" können.

    Autor: Trollversteher 17.11.20 - 09:35

    Sehe ich genau so, das war auch mein erster Gedanke, als ich die Artikelüberschrift las (und ich bin selbst "coder" und kein Projekt/Abteilungsleiter ;-) )

  15. Re: Nein, die müssen nicht "coden" können.

    Autor: jg (Golem.de) 17.11.20 - 11:29

    Hallo, ihr habt recht, die Headline ist etwas unglücklich. Wir ändern. Danke und Grüße, Juliane

    Juliane Gunardono
    Golem.de

  16. Re: Nein, die müssen nicht "coden" können.

    Autor: Pete Sabacker 17.11.20 - 11:33

    SchluppoMäcQuarkkeulchen schrieb:
    --------------------------------------------------------------------------------
    > Ich kann bis heute nicht "coden", auch wenn ich inzwischen natürlich mehr

    Wäre für mich ein Kündigungsgrund.

  17. Re: Nein, die müssen nicht "coden" können.

    Autor: Hallonator 17.11.20 - 12:30

    Pete Sabacker schrieb:
    --------------------------------------------------------------------------------
    > SchluppoMäcQuarkkeulchen schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ich kann bis heute nicht "coden", auch wenn ich inzwischen natürlich
    > mehr
    >
    > Wäre für mich ein Kündigungsgrund.

    Wieso?

    Bei mir ist zwar auch der Teamleiter der Ansprechpartner für Fragen in Richtung "Soll ich das so oder so machen? a) dauert länger, aber b) ist sauberer", aber theoretisch könnte ein Teamleiter architektorische Entscheidungen etc auch problemlos an ein anderes Teammitglied delegieren

  18. Re: Nein, die müssen nicht "coden" können.

    Autor: Pete Sabacker 17.11.20 - 13:24

    Theoretisch, ja. Habe ich in 10 Jahren jedoch nicht einmal erlebt, dass das durch einen Teamleiter auch geschah.

    Kürzlich ging der größte Firmendeal der Geschichte platzen, weil der Teamleiter sich einen Dreck um den technisch katastrophalen Zustand der Software scherte.

    Deshalb würde ich einen Job nie wieder dort beginnen, wo ein Teamleiter keine Ahnung von der Materie hat.

  19. Re: Nein, die müssen nicht "coden" können.

    Autor: .02 Cents 17.11.20 - 14:36

    Aus meiner Sicht ist die eigentliche Führungsaufgabe - von Zwischenmenschlichen Problemen abgesehen - in erster Linie administrativ. Je weiter rauf in der Führungsebene, je weniger hat die Aufgabe mit technischer Umsetzung zu tun.

    Ich habe gewisse Zweifel an der Effektivität von "Quereinsteiger-Führungskräften" - das will ich aber nur bedingt auf die "Codierfähigkeit" beschränken. Ich arbeite zum Beispiel fast ausschliesslich in Daten-Integrationsprojekten. Wenn da jemand ohne starken Daten Bezug als Führungskraft kommt, dann ist es fast egal, ob das jemand aus der GUI Entwicklung oder aus der Bauleitung ist (Übertreibung verdeutlicht ...).

    Umgekehrt müsste man natürlich auch fragen, was "Führungskraft" überhaupt bedeutet. Das ist sicher etwas anderes, ob man davon redet, ein Team im Betrieb zu leiten, oder dafür verantwortlich zu sein, dass ein Projekt / Programm im Plan fertig wird. Ich habe aber generell die Erfahrung gemacht, dass es für diese Aufgabe eher schädlich ist, wenn die "Führungskraft" sich in Details verliert und sich zu sehr um Umsetzungsdetails oder einzelne Tickets kümmert.

    Es kommt dazu, dass häufig genug eine Rolle wie der Projektleiter auch noch alle möglichen anderen Aufgaben / Rollen übernimmt. Das ist manchmal OK - bei 3 Projektbeteiligten ist das Planungs- und Koordinationsproblem zwangsläufig überschaubar. Wenn es aber 20-30-... Leute werden, die nur noch sehr ungefähr oder gar nicht mehr wissen, was genau die Leute ausserhalb des eigenen "Workstream" machen, dann ist die Koordination keine Nebenbeschäftigung mehr, und Coder-Fähigkeiten helfen höchstens noch, wenn man Aufwandschätzungen kritisch hinterfragen möchte.

  20. Re: Nein, die müssen nicht "coden" können.

    Autor: Trollversteher 17.11.20 - 15:10

    >Theoretisch, ja. Habe ich in 10 Jahren jedoch nicht einmal erlebt, dass das durch einen Teamleiter auch geschah.

    Dann lag da bei euch wohl so einiges im Argen, das heißt aber noch lange nicht, dass ein programmierender Projektleiter irgend etwas daran geändert hätte...

    >Kürzlich ging der größte Firmendeal der Geschichte platzen, weil der Teamleiter sich einen Dreck um den technisch katastrophalen Zustand der Software scherte.

    Siehe oben - da scheint eindeutig das "einen Dreck scheren" das Problem zu sein, aber nicht die fehlenden Programmierkenntnisse des Projektleiters. Ein guter Projektleiter weiß, wen seiner erfahrenen Entwickler er dabei zu Rate ziehen kann, der muss (und sollte auch) solche Entscheidungen nicht nach eigener Code-Expertise fällen.

    >Deshalb würde ich einen Job nie wieder dort beginnen, wo ein Teamleiter keine Ahnung von der Materie hat.

    Der Teamleiter schien eher keine Ahnung von der Materie "Teamleiter" zu haben, das hat doch nichts mit Programmierkenntnissen zu tun.

  21. Re: Nein, die müssen nicht "coden" können.

    Autor: Pete Sabacker 17.11.20 - 18:09

    Trollversteher schrieb:
    --------------------------------------------------------------------------------
    > >Theoretisch, ja. Habe ich in 10 Jahren jedoch nicht einmal erlebt, dass
    > das durch einen Teamleiter auch geschah.
    >
    > Dann lag da bei euch wohl so einiges im Argen, das heißt aber noch lange
    > nicht, dass ein programmierender Projektleiter irgend etwas daran geändert
    > hätte...

    Nunja, der Fisch stinkt immer vom Kopfe herab.

    > >Kürzlich ging der größte Firmendeal der Geschichte platzen, weil der
    > Teamleiter sich einen Dreck um den technisch katastrophalen Zustand der
    > Software scherte.
    >
    > Siehe oben - da scheint eindeutig das "einen Dreck scheren" das Problem zu
    > sein, aber nicht die fehlenden Programmierkenntnisse des Projektleiters.
    > Ein guter Projektleiter weiß, wen seiner erfahrenen Entwickler er dabei zu
    > Rate ziehen kann, der muss (und sollte auch) solche Entscheidungen nicht
    > nach eigener Code-Expertise fällen.

    Ihr scheint aber alle davon auszugehen, dass es immer nur 'gute' Leiter gibt. Ich habe halt das Gegenteil erlebt, nämlich fast immer von Egozentrik geprägte, die sich zuallererst um ihr eigenes Wohl scheren. Einmal ging das so weit, dass man den mit Sicherheitspersonal des Geländes verwiesen hat.


    > >Deshalb würde ich einen Job nie wieder dort beginnen, wo ein Teamleiter
    > keine Ahnung von der Materie hat.

    > Der Teamleiter schien eher keine Ahnung von der Materie "Teamleiter" zu
    > haben, das hat doch nichts mit Programmierkenntnissen zu tun.

    Nunja, in diesem Falle halt schon, weil sonst halt niemand Ahnung von Technik in dem Schuppen hat. Er ist der Einzige, dem man an der Stelle bei den Urteilen vertraute.

  22. Re: Nein, die müssen nicht "coden" können.

    Autor: Trollversteher 19.11.20 - 13:19

    >Nunja, der Fisch stinkt immer vom Kopfe herab.

    Nicht immer, aber häufig - und im Falle eines Projektleiters gibt es ja auch noch einige Köpfe darüber - zumindest scheint Dein Fall nicht darin begründet zu sein, dass ein Projektleiter niocht coden konnte...

    >Ihr scheint aber alle davon auszugehen, dass es immer nur 'gute' Leiter gibt. Ich habe halt das Gegenteil erlebt, nämlich fast immer von Egozentrik geprägte, die sich zuallererst um ihr eigenes Wohl scheren. Einmal ging das so weit, dass man den mit Sicherheitspersonal des Geländes verwiesen hat.

    Nö, da geht hier eigentlich niemand von aus, zumindest ich nicht, ich habe auch schon schlechte Projektleiter erlebt - das Thema war hier aber "Projektleiter sollten coden können" - und in der Regel hapert es bei einem schlechten Projektleiter an anderen Dingen als das.

    >Nunja, in diesem Falle halt schon, weil sonst halt niemand Ahnung von Technik in dem Schuppen hat. Er ist der Einzige, dem man an der Stelle bei den Urteilen vertraute.

    Ja sorry, aber dann stinkt der Fisch nicht nur vom Kopf des Projektleiters her, sondern von den Köpfen weiter oben. Und so wie Du ihn hier schilderst, hätte coding-Erfahrung daran auch nichts geändert.

  23. Re: Nein, die müssen nicht "coden" können.

    Autor: Pete Sabacker 19.11.20 - 16:30

    Trollversteher schrieb:
    --------------------------------------------------------------------------------
    > Ja sorry, aber dann stinkt der Fisch nicht nur vom Kopf des Projektleiters
    > her, sondern von den Köpfen weiter oben. Und so wie Du ihn hier schilderst,
    > hätte coding-Erfahrung daran auch nichts geändert.

    Naja, ich glaube eben doch, dass es genau der entscheidende Faktor ist, ich hab's nun oft genug erlebt. Dunning Kruger greift bei solchen Leuten zu oft, denn genau dieselben mischten sich in Technologieentscheidungen ein. Wenn ich aber schon zuvor Erfahrungen in der Branche beim Programmieren gesammelt habe, dann weiß ich ganz genau, wann ich das tun kann und wann nicht.

    Dass man von weiter oben da das Vertrauen in die falschen Leute setzt, das sehe ich genauso.

  24. Re: Nein, die müssen nicht "coden" können.

    Autor: Trollversteher 20.11.20 - 07:43

    >Naja, ich glaube eben doch, dass es genau der entscheidende Faktor ist, ich hab's nun oft genug erlebt. Dunning Kruger greift bei solchen Leuten zu oft, denn genau dieselben mischten sich in Technologieentscheidungen ein. Wenn ich aber schon zuvor Erfahrungen in der Branche beim Programmieren gesammelt habe, dann weiß ich ganz genau, wann ich das tun kann und wann nicht.

    Nein, sorry, wenn das jemand war, bei dem Dunning Kruger gegriffen hat, dann hätten daran auch coding Kenntnisse nichts geändert - ein Projektleiter, der sich auf Grund von einer länger zurückliegenden Coding Erfahrung für einen vollwertigen Entjwickler hält, und den Entwicklern in ihre Arbeit hineinpfuscht, ist auch vor Dunning Kruger nicht gefeit, im Gegenteil - und ich habe das selbst schon in einem Kundenprojekt erlebt, wo ein Abteilungsleiter der vor Jahrzehnten im Unternehmen mal als Entwickler angefangen hatte zum Projektleiter ernannt wurde, und meinte alles besser zu wissen obwohl er seine große Zeit als Entwickler in der 8086 IBM PC MS-DOS Ära hatte. Da wäre mir jemand komplett ohne coding Erfahrung *sehr viel* lieber gewesen.

    >Dass man von weiter oben da das Vertrauen in die falschen Leute setzt, das sehe ich genaus

    Wie gesagt, imho verstehst Du da die Rolle des Projektleiters falsch. Ein guter Projektleiter sucht sich ein paar erfahrene Senior Developer, auf deren Rat er vertrauen kann und übertröägt diesen die Rolle eines "technical lead", und lässt sich in solchen Fragen beraten. Dazu gehört natürlich auch ein grundlegendes technisches Verständnis, aber ansonsten ist Menschenkenntnis, Führungs- und Organisationstalent gefragt. Coding Kenntnisse sind da nur ein nettes "kann" aber sicher kein "muss".

  25. Re: Nein, die müssen nicht "coden" können.

    Autor: SchluppoMäcQuar... 17.11.20 - 15:00

    Pete Sabacker schrieb:
    --------------------------------------------------------------------------------
    > SchluppoMäcQuarkkeulchen schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ich kann bis heute nicht "coden", auch wenn ich inzwischen natürlich
    > mehr
    >
    > Wäre für mich ein Kündigungsgrund.

    Also stellst Du in dem von mir beschriebenen Szenario eine Person für die Führung ein und erwartest, dass sie programmieren lernt, erzählst es ihr aber nicht? Sollte in dem Szenario die Führungskraft lieber entwickeln statt führen? Oder mit den Entwicklern Code besprechen? Oder ist das so eine Idee von "der Chef muss alles können was die Entwickler können, damit er respektiert wird?".... sag mal was Dich zu Deiner Aussage bringt?

  26. Re: Nein, die müssen nicht "coden" können.

    Autor: Pete Sabacker 17.11.20 - 18:03

    Was mich zu der Entscheidung bewegt, habe ich ja weiter oben noch beschrieben. Für mich muss ein Teamleiter in der IT erkennen können, wenn die Qualität der Software derart abnimmt, dass das die gesamte Firma in wirtschaftliche Gefahren bringt.

  27. Re: Nein, die müssen nicht "coden" können.

    Autor: Hallonator 18.11.20 - 08:47

    Pete Sabacker schrieb:
    --------------------------------------------------------------------------------
    > Was mich zu der Entscheidung bewegt, habe ich ja weiter oben noch
    > beschrieben. Für mich muss ein Teamleiter in der IT erkennen können, wenn
    > die Qualität der Software derart abnimmt, dass das die gesamte Firma in
    > wirtschaftliche Gefahren bringt.

    Wirtschaftliche Gefahren stehen aber nicht im Code. Eine verdammt schlechte Codebasis kann wirtschaftlich verdammt gut laufen.

    Die Probleme erkennt die Führungskraft wohl eher daran, dass die Projekte immer langsamer fertig werden. Oder daran, dass sich laut Teams Features nicht mehr implementieren lassen. Oder daran, dass die Kunden immer mehr Probleme melden. Aber bestimmt nicht daran, dass Entwickler die Codebasis für Verbesserungswürdig halten, was in unserer Natur ist.

  28. Re: Nein, die müssen nicht "coden" können.

    Autor: Pete Sabacker 18.11.20 - 14:08

    Hallonator schrieb:
    --------------------------------------------------------------------------------
    > Pete Sabacker schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Was mich zu der Entscheidung bewegt, habe ich ja weiter oben noch
    > > beschrieben. Für mich muss ein Teamleiter in der IT erkennen können,
    > wenn
    > > die Qualität der Software derart abnimmt, dass das die gesamte Firma in
    > > wirtschaftliche Gefahren bringt.
    >
    > Wirtschaftliche Gefahren stehen aber nicht im Code. Eine verdammt schlechte
    > Codebasis kann wirtschaftlich verdammt gut laufen.
    >
    > Die Probleme erkennt die Führungskraft wohl eher daran, dass die Projekte
    > immer langsamer fertig werden. Oder daran, dass sich laut Teams Features
    > nicht mehr implementieren lassen. Oder daran, dass die Kunden immer mehr
    > Probleme melden. Aber bestimmt nicht daran, dass Entwickler die Codebasis
    > für Verbesserungswürdig halten, was in unserer Natur ist.

    2 Sprints pro Jahr. Wegen schlechter Codebasis und ausschließlich deshalb, gebe ich Dir als Entwickler wie einst auch Teamleiter in anderer Firma Brief und Siegel drauf. Und deshalb interessiert mich nicht, was sein kann - Meine Erfahrungen sind zu prägend und wiederholten sich zu oft, als dass irgendein 'kann' meine Meinung hier ändern kann.

  29. Re: Nein, die müssen nicht "coden" können.

    Autor: Trollversteher 19.11.20 - 13:35

    Es bestreitet ja niemand Deine schlechten Erfahrungen, oder dass dieser Projektleiter ganz offensichtlich in seinem Job versagt hat. Du ziehst halt nur die falschen Schlüsse daraus...

  30. Re: Nein, die müssen nicht "coden" können.

    Autor: Trollversteher 19.11.20 - 13:33

    Richtig.

  31. Re: Nein, die müssen nicht "coden" können.

    Autor: Trollversteher 17.11.20 - 15:06

    >Wäre für mich ein Kündigungsgrund.

    Dann hoffe ich, dass Du keine Personalverantwortung hast, bei der unprofessionellen Einstellung...

  32. Re: Nein, die müssen nicht "coden" können.

    Autor: Pete Sabacker 17.11.20 - 18:04

    Was Du hoffst, ist mir egal.

  33. Re: Nein, die müssen nicht "coden" können.

    Autor: Trollversteher 19.11.20 - 13:32

    >Was Du hoffst, ist mir egal.

    Was für eine professionelle, erwachsene Antwort - aber passt ins Bild...

    Wenn Du übrigenst nicht wünschst, dass andere auf Deine Aussagen eingehen, solltest Du vielleicht nicht in öffentlichen Foren solche provokativen Aussagen posten ;-)

  34. Re: Nein, die müssen nicht "coden" können.

    Autor: Pete Sabacker 19.11.20 - 16:27

    Trollversteher schrieb:
    --------------------------------------------------------------------------------
    > >Was Du hoffst, ist mir egal.
    >
    > Was für eine professionelle, erwachsene Antwort - aber passt ins Bild...

    Den Ball kann ich nur zurückspielen. Wer provoziert, muss sich nicht wundern, war schon immer so.

  35. Re: Nein, die müssen nicht "coden" können.

    Autor: Trollversteher 20.11.20 - 07:45

    >Den Ball kann ich nur zurückspielen. Wer provoziert, muss sich nicht wundern, war schon immer so.

    Nur das Du derjenige warst, als Du den TE nach seinem sachlichen und höflichen Beitrag "feuern" würdest - das hat mich ziemlich geärgert, nicht nur weil es fachlich völlig daneben war, sondern auch ein ziemlich persönlicher Angriff auf die Kompetenz des TE war - wie es in den Wald hineinschallt...

  36. Re: Nein, die müssen nicht "coden" können.

    Autor: it_bienchen 18.11.20 - 18:44

    Ich kann den Ansatz dieses Kommentars nachvollziehen, allerdings lag der Schwerpunkt des Artikels mehr in beförderten IT-Spezialisten. Führungskräfte im IT-Bereich können auch mit einem Basis-Wissen über Informatik und dessen Branche gut sein, ohne Coden zu müssen. Im Laufe der Zeit eignet man sich sowieso immer mehr Wissen zu seinem Bereich an.
    Im Falle von IT-Leuten, die eine neue personalleitende Funktion übernehmen müssen, sollte ebenfalls erwartet werden, dass ein Grundverständnis der Aufgaben vorhanden ist. Dies sollte aber bereits vor der Beförderungsentscheidung von den Aufsichtsleuten geprüft oder bei Bedarf weitergebildet werden.

  37. Re: Nein, die müssen nicht "coden" können.

    Autor: mke2fs 19.11.20 - 11:02

    Ein Teamleiter sollte schon Ahnung davon haben von dem was er leitet.
    Was dabei raus kommt wenn er es nicht hat sieht man in der Verwaltung auf hoher Ebene oder in der Politik, da wird fleißig am Thema vorbeigearbeitet/die Leute die die Arbeit machen fassen sich an den Kopf ob der Vorgaben.

    Sicher kann sich ein guter Teamleiter auch ohne Fachkenntnisse einarbeiten.
    Das gleiche gilt auch in der Gegenrichtung, auch ein Fachidiot (nicht negativ gemeint) kann sich in Teamführung einarbeiten.
    Aber in der Regel funktioniert es wesentlich schlechter.

    Was ein Teamleiter nicht tun sollte:

    - Mircomanagement - nur weil man mal Entwickler war, heißt das nicht das man als Führungskraft dann weiterhin im Code herumpfuschen muss/sollte
    - seinen Stil allen anderen aufdrücken - ja man kann es jetzt, aber man leitet jetzt ein Team und ist dafür zuständig das es gut arbeitet und das wird nichts wenn man seine Vorstellungen durchprügelt

    Leider wählen die Ebenen die Führungskräfte einsetzen häufig Leute die technisch sehr gut waren in Leitungspositionen.
    Das nennt man das Peter-Prinzip, das besagt: Jeder steigt so lange auf bis er die Stelle erreicht hat für die er am meisten ungeeignet ist/wo er am inkompetentesten ist.
    Leute die technisch gut sind, sind technisch gut, das heißt (schließt es aber nicht aus) das sie gut Leute führen können, was die Kernkompetenz eines Leiters wäre.

  38. Re: Nein, die müssen nicht "coden" können.

    Autor: Hallonator 19.11.20 - 13:07

    mke2fs schrieb:
    --------------------------------------------------------------------------------
    > Sicher kann sich ein guter Teamleiter auch ohne Fachkenntnisse
    > einarbeiten.
    > Das gleiche gilt auch in der Gegenrichtung, auch ein Fachidiot (nicht
    > negativ gemeint) kann sich in Teamführung einarbeiten.
    > Aber in der Regel funktioniert es wesentlich schlechter.
    Was zu beweisen wäre!

    Viele Fähigkeiten, die zur Teamführung nötig sind, lernen die meisten Techniker einfach nie.

    > Was ein Teamleiter nicht tun sollte:
    [...] Hier folgt eine Aufzählung, von Problemen, die sich aus dem Irrglauben ergeben, dass man aus fachlich guten Leuten auch gute Führungskräfte machen kann.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. PHP Entwickler / Developer Backend (m/w/d)
    Digital Shipping GmbH, deutschlandweit (Home-Office)
  2. Produktdatenmanager (m/w/d)
    Zeitfracht GmbH, Stuttgart
  3. Projektleiter SAP HCM Inhouse (m/w/d)
    Jungheinrich AG, Hamburg
  4. Senior Referent IT / Security Engineer (m/w/d)
    L-Bank, Karlsruhe

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 499,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Energiespeicher: Große Druckluftspeicher locken Investorengelder an
Energiespeicher
Große Druckluftspeicher locken Investorengelder an

Hydrostor bietet eine langlebige Alternative zu Netzspeichern aus Akkus, die zumindest in den 2020er Jahren wirtschaftlich ist.
Von Frank Wunderlich-Pfeiffer

  1. Energiewende Akkupreise steigen wegen zu hoher Rohstoffkosten
  2. Nachhaltigkeit Mehr Haushalte investieren in die Energiewende
  3. P2P-Energiehandel Lieber Nachbar, hätten Sie noch etwas Strom für mich?

Sportuhr im Hands-on: Garmin Fenix 7 mit Touchscreen und Saphirglas-Solarstrom
Sportuhr im Hands-on
Garmin Fenix 7 mit Touchscreen und Saphirglas-Solarstrom

Bis zu 37 Tage Akku und erstmals ein Touchscreen: Golem.de hat bereits die Outdoor-Smartwatch-Reihe Fenix 7 von Garmin ausprobiert.
Von Peter Steinlechner

  1. Wearable Garmin Fenix 7X offenbar mit bis zu 37 Tagen Akku

Treibstoffe: E-Fuels-Produktion in der Praxis
Treibstoffe
E-Fuels-Produktion in der Praxis

Über E-Fuels, also aus Ökostrom hergestellte Kraftstoffe, wird viel diskutiert. Real produziert werden sie bislang kaum.
Von Hanno Böck

  1. Eisenoxid-Elektrolyse Stahlherstellung mit Strom statt Kohle