Informatiker: Jobvorschläge? Wunsch: Zeitliche Flexibilität!

[Der_Picknicker]

@Cokocool …

Top danke dir vielmals!

 

[gymfan]

Sich die Frage zu stellen, welchen Job es gibt, der langfristig in Teilzeit ausführbar ist (z.B. 30-35h)

Das dürfte auch heute noch sehr stark vom AG abhängen und vermutlich in tarifgebundenen Konzernen (oder jedenfalls in größeren Betrieben) eher realisierbar sein wie in kleinen Startups. Bis auf die echte Produktion und u.U. ein paar Tätigkeiten in der Forschung ist bei uns quasi alles in Teilzeit möglich. Die Frage ist dann eher, wie man, gerade in der IT, diese Teilzeit mit den Kollegen zusammen planen kann.

Meine Ex-Cheffin hat den Job von Anfang an in Teilzeit gemacht. Trotzdem war klar, dass die auch regelmäßig 2nd-Level Support (damals noch zwingend vor Ort) machen müsste, was entweder von 7:00-11:30 oder von 11:30-16:00 war. Sowas war für sie nur möglich, weil an den Tagen, an denen sie um 7 Uhr vor Ort sein musste, ihr Mann die Kinder in die Kita/Grundschule gebracht hat.

Mittags ab 13 Uhr musste man auch keine Meetings mehr ansetzen, um 14 Uhr war sie spätestens weg. damit gab es tendenziell mehr Regeltermine, die zur Not kurzfristig abgesagt wurden. Dinge, die man sonst über den Tag mal schnell im Großraumbüro abgestimmt hat, wenn der Chef gerade am Platz war, musste man dort vormittags abstimmen. Wenn man eine vergleichbare Anzahl an festen Terminen über 5-6 h/Tag bündeln muss, bleibt weniger nicht verplante Zeit für spontanes übrig.

Wir haben sehr viele Kollegen, die in ihrem Kalender alles nach 14:30 geblockt haben, weil sie in Teilzeit arbeiten. Die Firmenkultur macht sowas mit und in Ausnahmefällen wird trotzdem "erwartet", dass auch solche MA mal auf mehrtägige Dienstreise oder zu einer dienstlichen Abendveranstaltung mit ext. Gästen gehen können. Wer das grundsätzlich nicht kann, muss sich betriebsintern einen entsprechenden Job suchen, der in der Kernarbeitszeit nur am Standort zu erledigen ist.

Eure Kommentare zeigen teilweise ja ebenfalls, dass dies eigentlich euer Wunsch wäre.

Klar, am liebsten wäre mir FIRE schon vor 10 Jahren gewesen und ich würde seitdem nur noch das machen, was ich gerne möchte. Das klappt bei mir aber selbst mit Anfang 50 noch nicht, dazu fehlt nicht nur das passende Erbe.

Neben dem konzerninternen Wechsel auf eine Stelle, auf der ich die zu mir passenden Arbeitszeiten habe (in der Regel 8:30 bis 17:30) folgt demnächst noch der Wechsel von 40h zu 37,5h. 37,5-40h gilt bei uns als Vollzeit, womit Zulagen (Bonus, Jahresleistung, Urlaubsgeld) entsprechend berechnet werden. Das liegt aber an der seltsamen, betriebsinternen Auslegung des Tarifvertrages.

Weniger Stunden will ich derzeit nicht, da ich ins Langzeitkonto spare und damit ein paar Jahre früher in Vorruhestand gehe, während ich noch bei der Firma angestellt bin.

Ein paar Kollegen finanzieren über das Langzeitkonto ihre "Teilzeit", indem sie nur noch 20-30h/Woche arbeiten, den Rest über das Langzeitkonto finanzieren und damit immer noch als Vollzeitangestellte gelten (und auch das entsprechende Nettogehalt bekommen). Und wieder andere sind ganz "einfach" in Teilzeit mit entsprechend real geringerem Gehalt. Und andere finanzieren sich darüber das schon angesprochene Sabbatical.

Interessant. Genau solche praktischen Erfahrungen interessieren mich. Womöglich gibt's nämlich meinen Traumjob (mit nur 2-4h Meetings täglich) doch irgendwo.

Da sind wir fast alle drunter, jedenfalls im Schnitt. Das hat für mich nur sehr bedingt etwas mit flexiblen Arbeitszeiten zu tun. Wenn Regelmeetings um 9 Uhr angesetzt sind, dann kann man zwar versuchen, diesen Regeltermin zu verschieben. Das klappt aber nicht, wenn die Führungskraft um 10 Uhr wieder ihre Meetings mit der Führungsriege hat. Kommen dann noch Projektmeetings dazu, dann werden die vom Projektmanagement nach Möglichkeit so getaktet, dass sie zu den Terminen passen, welche die Regelteilnehmer schon haben. Damit müssen sie auch zu den Abläufen im Betrieb passen und man setzt sie auch gerne mal um 8 Uhr an.

Hat man in seinem Job auch noch so ehrenvoll Aufgaben wie Du (Kundensupport, bei mir war das Jahrelang 2nd und 3rd Level Support für ein IT-System in der Produktion), dann sind diese Tage (wir haben uns mit ein paar Kollegen abgewechselt) nur in den Erreichbarkeitszeiten/Anwesenheitszeiten planbar. Mal kam 4,5h keine einzige Anfrage, mal stand das Telefon nicht still und die Schicht war nur theoretisch um 16 Uhr zu Ende. Das System musste schließlich wieder laufen und die Arbeitszeit an dem Tag war nur durch die Zeiterfassung (max 10,45h am Tag) beschränkt.

Überstunden werden aber alle aufgezeichnet und sollen innerhalb eines Jahres abgebaut werden. Werden es zu viele, dann schreitet erst der Chef ein, und wenn das nichts hilf auch noch dessen Chef und HR. Damit wird man zur Not in Zwangsurlaub geschickt, sobald es sich aus Sicht der Chefs irgendwie mit der Arbeit vereinbaren lässt. Für mich ist das System seit >10 Jahren einer der Gründe, lieber in der höchsten Tarifstufe zu bleiben wie nach AT (mit Vertrauensarbeitszeit) zu wechseln.

Ich habe auf Stepstone mal nach "System Owner" gesucht um zu verstehen wie dort die Jobbeschreibungen sind.

Bei uns sind die Owenschaften zweigeteilt:
Der "Process Owner" ist für die Anforderungen an das IT-System aus Anwendersicht verantwortlich (User Requirements) und am Ende auch dafür zu entscheiden, ob ein Fehler/Systemausfall des IT-Systems Auswirkung auf die Produktion oder gar das Produkt hat.

Der "System Owner" ist für den Betrieb des IT-Systems verantwortlich. Also die Realisierung der User Requirements, den technischen Betrieb, den User-Support/die Schulungen usw.

Das sind bei uns immer zwei getrennte Rollen aus getrennten Bereichen, einmal beim Anwender/Betreiber/Produzenten und einmal in der IT.

Je nach Größe des Systems ist der System Owner dann in Personalunion für alles verantwortlich oder delegiert Teile der Aufgaben. Bisher ist es da oft so, dass eine Führungskraft in Personalunion sowohl System Owner für ein oder mehrere Systeme ist, die Aufgaben aber entsprechend delegiert. Dazu kommt die Personalführung für eben diese Mitarbeiter.

In so einem Fall hat die Führungskraft Meetings in beiden Verantwortungsbereichen. Sowohl Personalführung (eigen MA sowie die Berichtskaskade aufwerts) wie auch fachlich. Das bedeutet nicht zwingend tiefe Einblicke in die Technik aber mind. das Wissen, was in dem System gerade vorgeht, welche Aufgaben anstehen, und die Budgetverantwortung dafür gegenüber den entsprechenden Gremien. Und dann auch noch die strategische Weiterentwicklung, je nach Konzerngröße nicht nur am eigenen Standort sondern Bundes- oder gar Weltweit.

Wie schon erwähnt wurde, klappt das nur für die Teamleitung, die Ebenen darüber können das Wissen in den einzelnen Systemen weder haben noch ist es ihre Aufgabe.

Wenn ich das richtig sehe, hat eine Führungskraft tendenziell weniger feste Meetings als ein Projektleiter, oder?

Bei uns eher nicht. Teamleiter haben halt die Abstimmungen (Personell und einem gewissen technischen Teil) zu treffen, und die Ebenen ab Abteilungsleiter dürfen sich dann, neben der Koordination ihrer Teams, auch um strategische Themen, gerne auch standortübergreifend, kümmern. Da mag es weniger Regeltermine geben, trotzdem ist der Terminkalender von den Kollegen meist eher überfüllt (und zwar nicht mit privaten Terminblockern).

Aus dem Projektmanagement kommend, kann ich mir trotz Informatik-Studium aber nur schwer vorstellen, dass Softwareentwickler (wo ich das Problem vielleicht nicht hätte) mich als Führungskraft präferieren würden.

Bei uns werden die Stellen weniger durch die demokratische Entscheidung der zukünftigen MA besetzt, sondern durch entsprechende Auswahlverfahren vom Management. Ob sich dann am Ende jemand als Führungskraft eignet ist dann eher die Frage, wie gut er die Aufgaben dieser Führungsrolle ausfüllen kann und nicht, welche Ausbildung er/sie hat.

Ich bin auch zu Zeiten, als ich die Rollen eines SW-Entwicklung oder SW-Architekten inne hatte, nicht mit technischen Fragen zu meinem Teamleiter gegangen. Da mussten wir ihn allenfalls mal von der Nutzung einer neuen Technologie überzeugen (was ja meist mit einem gewissen Anfangsinvest verbunden ist). Und sonst war er eher dafür zuständig, die Entwicklung gegenüber den Kunden und/oder der Führungsetage zu vertreten oder bei Störfällen das Management bei Laune und vor allem von uns fern zu halten :-) Da würde ein IT-Background sehr gut helfen, weil so jemand die technischen Probleme viel schneller versteht und hoffentlich als Führungskraft auch die Gabe mitbringt, das Problem für Kunden und Abteilungsleitung verständlich zu erklären.

 

[Pogrommist]

@Cokocool
Ist das 100% Remote..? Weil ich kenne eigentlich gar keine US-Firma die hier nen Sitz hat

Sind schon einige. Da es i.d.R. die sind, die am besten zahlen, wäre Levels die 1. Anlaufsstelle.
https://www.levels.fyi/leaderboard/Software-Engineer/All-Levels/country/Germany/

 

[te one]

Was ist denn für Dich „produktive Arbeit“?

D.h. es kommt nicht auf die Anzahl der Stunden im Meeting an, sondern auf das Thema. Eine 8 stündiger Workshop mit Entwicklern über die beste Softwarearchitktur würde Dich vermutlich eher inspirieren als abschrecken.

Gute Frage. Tatsächlich kann ich das schwer definieren. Zwischen Meetings hopsen und diese zwischendurch nicht nachbereiten zu können empfinde ich als unproduktiv. Mit Architekten eine SW-Architektur zu besprechen (da bin ich nicht der Tiefste in der Technik, habe aber das große Ganze und die Kundensicht auf dem Schirm) finde ich absolut inspirierend.

Ok, d.h Du hast mindestens drei Jobs auf einmal. Das ist schon mal problematisch. Und wenn Du ein „Team von Projektmanagern“ führst, warum delegierst Du keine Aufgaben an sie?
Man kann auch schlecht Product Owner für mehrere Produkte sein.

Das trifft es wohl.
Ich habe derzeit als PO zwei Entwicklungsteams (je 5 Personen). Eines entwickelt anhand der von mir erstellten internen Roadmap, das andere arbeitet an externen Aufträgen/Projekten (da halte ich mich ziemlich raus und bin froh, dass es irgendwie läuft). Ich werde mich hier in Kürze aber aus allen täglichen Meetings der Teams rausnehmen und wirklich nur noch zu Sprintbeginn/-ende eingreifen.
Die Anzahl unserer eigenen Produkte versuche ich derzeit von 4 auf 2 zu drücken - das war für die Entwicklung viel zu viel und der gesamte Fokus ging verloren.
Mein "Team" hat sich personell leider mehrfach verändert, weshalb ich derzeit nur einen Mitarbeiter habe, den ich gerade einlerne. Dem werde ich den gesamten Kundensupport übergeben.
Wenn das alles wirkt, habe ich hoffentlich zeitnah wieder Luft zum atmen.

Was ich an Deiner Stelle alternativ oder zusätzlich mal überlegen würde, wäre dass Du Dir einen Coach holst und Dir erst mal selber klar wirst, was Deine Prioritäten sind.

Konkrete Empfehlungen? Was wäre das für ein Coach? Braucht der IT-Erfahrung oder kann er aus einer ganz anderen Richtung kommen?

Naja, ne nach Aufgabe sind Meetings eben der Kernpunkt. Man synched und macht strategische Planung und kommuniziert diese aber setzt es nicht um.

Was mir wahnsinnig helfen würde wäre eine Matrix, in der man je nach Stellenbezeichnung/Joblevel die durchschnittliche tägliche Meeting-Stundenzahl sieht. Gibt's vermutlich nicht... Würde mir aber wahnsinnig helfen um mal zu wissen wo meine Reise hingehen soll.
Denn ob ich nun 80k oder 90k verdiene... Wenn ich in einem Job 70% in "nervigen" Meetings sitze und beim anderen nur in 30% - dann fiele die Wahl klar auf 30%. Ausgenommen sind unregelmäßige Meetings, in denen ich mit anderen wirklich eine geile Lösung/Architektur/... entwerfe.

Ich habe bin 56, habe >100K Gehalt + Dienstwagen + Firmenanteile und einen recht relaxten Job.
Dafür hat meine aktuelle Rolle etwas weniger Status als meine bisherigen Jobs. Aber das ist mir auch weniger wichtig als früher...

Generell gilt die Regel, je näher am Kunden die eigene Rolle ist, desto weniger kann man seinen Arbeitslast planen.

Wärst du bereit mal etwas von deinem Werdegang zu teilen? Auch gerne per PN. Deine Antworten waren bisher sehr treffend und haben mich schon ein ganzes Stück weiter gebraucht.
Der Punkt mit der Kundennähe ist sehr gut. Deshalb delegiere ich diesen Part (zumindest Support) wie oben beschrieben zukünftig.

Wenn Regelmeetings um 9 Uhr angesetzt sind, dann kann man zwar versuchen, diesen Regeltermin zu verschieben. Das klappt aber nicht, wenn die Führungskraft um 10 Uhr wieder ihre Meetings mit der Führungsriege hat. Kommen dann noch Projektmeetings dazu, dann werden die vom Projektmanagement nach Möglichkeit so getaktet, dass sie zu den Terminen passen, welche die Regelteilnehmer schon haben.

Ich habe absolut nichts gegen ein Regelmeeting um 9. Auch erwarte ich nicht, dass jeden Tag die Meetings nach meinem Gusto umgeschoben werden. Derzeit bin ich halt die Führungskraft, nach der viele ihre Meetings richten (weil sonst nichts mehr in meinem Kalender frei ist). Daraus folgt, dass fast alle meine Slots gefüllt werden und ich dadurch halt maximalst unflexibel bin. Aber wie oben gesagt liegt das wohl allgemein an der Menge meiner Aufgaben, die eigentlich auf mehrere Personen aufgeteilt werden sollten.

Der "Process Owner" ist für die Anforderungen an das IT-System aus Anwendersicht verantwortlich (User Requirements) und am Ende auch dafür zu entscheiden, ob ein Fehler/Systemausfall des IT-Systems Auswirkung auf die Produktion oder gar das Produkt hat.

Der "System Owner" ist für den Betrieb des IT-Systems verantwortlich. Also die Realisierung der User Requirements, den technischen Betrieb, den User-Support/die Schulungen usw.

Zu "Process Owner" findet man einige Jobangebote. Die Anforderungsprofile klingen sehr BWL-Lastig. Bei "System Owner" bleibt das Problem, dass ich kaum Stellenanzeigen finde. Vermutlich wäre letzteres eher passend für meinen IT-Hintergrund (wenngleich dieser eher breit als tief ist), oder?

Teamleiter haben halt die Abstimmungen (Personell und einem gewissen technischen Teil) zu treffen, und die Ebenen ab Abteilungsleiter dürfen sich dann, neben der Koordination ihrer Teams, auch um strategische Themen, gerne auch standortübergreifend, kümmern. Da mag es weniger Regeltermine geben, trotzdem ist der Terminkalender von den Kollegen meist eher überfüllt (und zwar nicht mit privaten Terminblockern).

Ob sich dann am Ende jemand als Führungskraft eignet ist dann eher die Frage, wie gut er die Aufgaben dieser Führungsrolle ausfüllen kann und nicht, welche Ausbildung er/sie hat.

Okay, daraus schließe ich, dass ich niemals Senior-Entwickler sein musste um als Führungskraft für ein Entwicklungsteam eingestellt zu werden.
Wenn ich allerdings lese, dass auch die Teamleiter überfüllte Kalender haben führt mich das ein Stück weit zurück zum anfänglichen Problem, ob ich überhaupt auf diesem Level unterwegs sein möchte. Ein Softwareentwickler macht ebenfalls gutes Geld und hat (zumindest bei uns) eher nur Dailies und vielleicht mal ein weiteres Meeting am Tag -> Die sind auch mal den ganzen Tag unterwegs und arbeiten dann halt in den Abendstunden.

 

[Pogrommist]

Das trifft es wohl.
Ich habe derzeit als PO zwei Entwicklungsteams (je 5 Personen). Eines entwickelt anhand der von mir erstellten internen Roadmap, das andere arbeitet an externen Aufträgen/Projekten (da halte ich mich ziemlich raus und bin froh, dass es irgendwie läuft). Ich werde mich hier in Kürze aber aus allen täglichen Meetings der Teams rausnehmen und wirklich nur noch zu Sprintbeginn/-ende eingreifen.
Die Anzahl unserer eigenen Produkte versuche ich derzeit von 4 auf 2 zu drücken - das war für die Entwicklung viel zu viel und der gesamte Fokus ging verloren.
Mein "Team" hat sich personell leider mehrfach verändert, weshalb ich derzeit nur einen Mitarbeiter habe, den ich gerade einlerne. Dem werde ich den gesamten Kundensupport übergeben.
Wenn das alles wirkt, habe ich hoffentlich zeitnah wieder Luft zum atmen.

Externe Aufträge und Kundensupport klingen für mich eher nach einem Dienstleister als nach Startup. Aber egal - eine frisch eröffnete Dönerbude kann man auch startup nennen

 

[TomH22]

Eines entwickelt anhand der von mir erstellten internen Roadmap, das andere arbeitet an externen Aufträgen/Projekten (da halte ich mich ziemlich raus und bin froh, dass es irgendwie läuft).

Im Idealfall trennt man Produktentwicklung und Service komplett voneinander, auch personell. Haben die Aufträge/Projekte was mit Euren Produkten zu tun (sind also ggf. Implementierung auf Basis der Produkte, oder komplett unabhängig)?

Was mir wahnsinnig helfen würde wäre eine Matrix, in der man je nach Stellenbezeichnung/Joblevel die durchschnittliche tägliche Meeting-Stundenzahl sieht. Gibt's vermutlich nicht

Die kann es nicht geben, weil wie ich schon sagte, hängt das nicht an der Stellenbezeichnung, sondern an der individuellen Organisation des Unternehmens und/oder Projektes. Das ist selbst innerhalb der gleichen Firma nicht einheitlich.

Wenn ich in einem Job 70% in "nervigen" Meetings sitze

...dann ist das Organisationsversagen. Je nach Deinem Einfluss auf die Organisation hast Du es in der Hand zu ändern, oder eben auch nicht.

Wärst du bereit mal etwas von deinem Werdegang zu teilen?

Ob der so nützlich für Dich ist, ist halt die Frage. Ich habe schon vor dem Abitur meine erste kleine Softwarefirma gegründet. Wirklich erfolgreich war ich ab 1996, als ich mit drei SAP ABAP Entwicklern zusammen eine Firma gegründet habe. Die Anfangszeit nenne ich gerne "Freelancer Selbsthilfegruppe", da einfach jeder seine Projekte hatte. Wir haben und dann später auf SAP LES (Lagerverwaltung und Transport vereinfacht gesagt...) fokusiert und auch eigene SAP AddOns dazu entwickelt. Wir haben dabei das SAP typische Bodyleasing vermieden, bei uns konnte man also nicht "100 Manntage Mitarbeiter X" mieten sondern nur Projekte im Zusammenhang mit SAP LES und bevorzugt mit unseren Produkten.
Um 2006/2007 hatte das Unternehmen ca. 20 Mitarbeiter und wir sind mit einer größeren Firma fusioniert. Seitdem habe ich da recht viele verschiedene Rollen inngehabt. Den größeren Teil der Zeit war ich dort Leiter unserer gesamten SAP Entwicklung (SAP AddOn Produkte + Service da herum).

Seit 2020 habe ich das an meine Nachfolger übergeben, das war nur so halb geplant.
Ich bin dann von unsere deutschen Niederlassung nach NL (da sitzt die Mutter) gewechselt und habe auch das SAP Business komplett verlassen und kümmere mich jetzt um "Cloud FinOps" für unsere Cloud Native Anwendungen auf Azure. Dabei arbeite ich mit einem kleinen und jungen Team.

"Statustechnich" (wenn man Status an Anzahl "Untergebener" definiert) ist das natürlich ein Rückschritt, aber es macht ungeheuer Spaß (ich konnte den SAP "Scheiß" nach 20 Jahren echt nicht mehr sehen) und es stimmt finanziell auch. Und meine Work Lifebalance ist phantastisch, was auch damit zu tun hat, das ich überhaupt nichts mit Kunden zu tun habe. Ich mache fast 100% Home Office, unser Team ist eh über drei Länder verteilt (Deutschland, Niederlande, Rumänien).

Daraus folgt, dass fast alle meine Slots gefüllt werden und ich dadurch halt maximalst unflexibel bin.

Bei uns ist üblich, das Leute einfach im Kalender Bereiche als "Fokuszeit" blocken. Das machen alle, auch unser CEO, usw.
Es ist im Unternehmen auch Usus, das man das respektiert.

Ein Softwareentwickler macht ebenfalls gutes Geld und hat (zumindest bei uns) eher nur Dailies und vielleicht mal ein weiteres Meeting am Tag

Nicht unbedingt. Gerade bei Kundenprojekten passiert es, zumindest bei uns, auch recht häufig, das ein Entwickler sehr intensiv als "Experte" eingebunden wird. Und in der Regel bedeutet dass dann Überstunden, denn die liegengebliebenen Entwicklungsaufgaben muss man dann halt Abends nachholen.

Und Entwickler ohne Führungsverantwortung bleiben dann halt Gehaltstechnisch irgendwann mal stehen.
Ist auch logisch:
Es gibt zwar Aufgaben, wo er Senior viel schneller als ein Junior ist, es gibt aber auch viel Routinecoding, wo jemand mit einem Jahr Erfahrung nicht langsamer als jemand mit 10 Jahren ist.
Also ich rechne immer das ein Senior im Mittel ca. die 1,5 fache Leistung eines eingearbeiteten Juniors hat.
D.h. er kann auch maximal das 1,5 fache Gehalt bekommen. In Zeiten von Fachkräftemangel kann sich das mal verzerren, aber sobald sich die Lage entspannt, pendelt sich das Gehaltsniveau langsam wieder auf normale Werte ein.

Konkrete Empfehlungen? Was wäre das für ein Coach? Braucht der IT-Erfahrung oder kann er aus einer ganz anderen Richtung kommen?

Er/Sie sollte im Idealfall die IT Branche kennen, muss aber nicht selber einen IT Background haben. Ich schreibe Dir mal ein PN dazu.

Externe Aufträge und Kundensupport klingen für mich eher nach einem Dienstleister als nach Startup

Naja, die meisten Startups die organisch wachsen und nicht über einen externen Kapitalgeber, haben eine Mischung aus Auftragsarbeiten und eigenen Produkten. Irgendwo muss das Geld ja herkommen.
Und dann gibt es eben auch bei vielen Produkten auch Implementierungsprojekte.

 

[Skysnake]

Im Idealfall trennt man Produktentwicklung und Service komplett voneinander, auch personell.

Finde ich jetzt eher suboptimal. Ich bin eher der Freund von du entwickelst es also betreibst du es auch mit Fokus auf DevOpsSec.

Das verhindert recht gut das Leute nen nicht wartbaren bzw betreibbaren Rotz erstellen.

Also ich rechne immer das ein Senior im Mittel ca. die 1,5 fache Leistung eines eingearbeiteten Juniors hat.
D.h. er kann auch maximal das 1,5 fache Gehalt bekommen.

Hmm... gibt es dann noch den Expertin bei dir? Gibt aus meiner Sicht öfters den Fall, dass der Junior die Aufgabe eben überhaupt nicht erledigt bekommt...

 

[TomH22]

Finde ich jetzt eher suboptimal. Ich bin eher der Freund von du entwickelst es also betreibst du es auch mit Fokus auf DevOpsSec.

Wenn man die Software überhaupt selber betreibt...
Bei klassischen On-Premise Produkten, die der Kunde bei sich installiert, hat man ja die operative Verantwortung nicht. Dafür muss man aber den Kunden supporten, egal wie (in)kompetent der dabei ist.
Nach meiner Erfahrung verwandelt sich das Entwicklungsteam, wenn man es nicht vom Kunden abschirmt, früher oder später in ein Support Team und es entwickelt keine Features mehr. Der Product Owner endet dann im Sandwich zwischen den Bedürfnissen der verschiedenen Stakeholder (z.B. bei uns Produkt Manager auf der Produktseite und Projekteiter auf der Kundenseite).

Damit verbrennt man dann zuverlässig das Personal, und besonders die Fähigeren sind dann die die zuerst kündigen...
Der TE ist in meinen Augen genau in so einer Situation.

Im SaaS Bereich macht man natürlich DevOps, aber auch da muss man sich mit dem Problem auseinandersetzen, wie man seine DevOps Teams davor schützt von den Kunden aufgerieben zu werden.

Das kann man z.B. dadurch machen, das man mehrere DevOps Teams hat, und dabei Teams die sich mehr auf Features fokussieren und welche die eher den "Ops" Teil und die Wartung im Auge haben.

Wie auch immer man sich organisiert: Sobald Leute zwischen widerstrebenden Zielen und zu viel Arbeitsbelastung aufgerieben werden, muss man die Organisation anpassen.

Gibt aus meiner Sicht öfters den Fall, dass der Junior die Aufgabe eben überhaupt nicht erledigt bekommt

Ich habe ja nicht gesagt, das ein Team nur aus Junioren besteht. Der Mix macht es. Aber trotzdem waren in meiner aktiven Zeit in Deutschland Entwickler ohne Führungsverantwortung mit >80 K EUR Jahresgehalt die Ausnahme.

 

[te one]

Der Product Owner endet dann im Sandwich zwischen den Bedürfnissen der verschiedenen Stakeholder (z.B. bei uns Produkt Manager auf der Produktseite und Projekteiter auf der Kundenseite).

Damit verbrennt man dann zuverlässig das Personal, und besonders die Fähigeren sind dann die die zuerst kündigen...
Der TE ist in meinen Augen genau in so einer Situation.

Exakt so ist es - wobei in meinem Fall der größte Teil der beschriebenen Aufgaben in mir als Person gebündelt sind/waren.
Projektleitung/Kundensupport (also alles kundenseitige) versuche ich nun in mein wachsendes Team zu delegieren.
Weiterhin sammle ich als Product Owner (bin gerade am optimieren des Prozesses, vielleicht hat ja jemand spontane Tipps) die Needs aller Bereiche (Vertrieb, Support, Entwicklung, ...) und definiere mit den Teamleads + CEOs Produktziele für die nächsten 3-6 Monate. Als PO schnüre ich daraufhin eine Roadmap für unsere Entwicklung. Die anderen Bereiche erstellen aus den Produktzielen ihre eigenen Roadmaps, die dann parallel in den Teams ablaufen.