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
  1. 1
  2. 2

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: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 ;-) )

  4. 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.

  5. 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...

  6. 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.

  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: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 ;-)

  12. 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 ;-)

  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: 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.

  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: SchluppoMäcQuarkkeulchen 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?

  1. Thema
  1. 1
  2. 2

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. IT-Systemadministrator (m/w/d)
    Stadtverwaltung Uhingen, Uhingen
  2. Qualitätssicherung Softwaretester (m/w/d)
    secunet Security Networks AG, Essen
  3. IT-Servicetechniker (m/w/d) - Bank Technologie
    GRG Deutschland GmbH, Hamburg
  4. Senior Cloud Engineer (m/w/d)
    unimed Abrechnungsservice für Kliniken und Chefärzte GmbH, Wadern (Home-Office möglich)

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 888€ (Bestpreis)
  2. 777€ (Bestpreis)
  3. (u. a. Game of Thrones - Die komplette Serie Blu-ray für 79,97€)
  4. (u. a. Monitore und PC-Komponenten nach Marken sortiert und zu drastisch reduzierten Preisen)


Haben wir etwas übersehen?

E-Mail an news@golem.de