Enterprise-Erfahrung

• Ein Jahr Arbeit in einem Großunternehmen machte die deutlichen Unterschiede zu bisherigen Umgebungen in Startups und SMEs spürbar
• Durch die komplexere Zuordnung von Verantwortlichkeiten und interne Prozesse werden Punkte, die in kleinen Organisationen kein Problem waren, zu unlösbaren Aufgaben
• Ressourcenverschwendung und unausgewogene Einstellungsmaßstäbe führen zu Problemen bei Effizienz und Motivation der Organisation
• Wichtige Konzepte innerhalb der Organisation wie Dringlichkeit von Aufgaben und Sicherheitsmanagement werden entgegen ihrer eigentlichen Bedeutung zu formalen, prozeduralen Handlungen
• Trotz der verschiedenen Probleme gibt es auch positive Erfahrungen wie Kompetenzentwicklung und Karrierewachstum

---

Rückblick auf 1 Jahr Enterprise-Erfahrung

Unterschiede zwischen Großunternehmen und Startup

• Im ersten Jahr bei $ENTERPRISE wurden die Unterschiede zu bisherigen Startups und SMEs (kleinen und mittleren Unternehmen) deutlich.
• Später wurde erkannt, dass mangelnde Erfahrung in der internen Softwareentwicklung großer Unternehmen kein Kritikpunkt, sondern eher ein positives Signal ist.
• Die beobachteten Punkte fassen die Realität des Arbeitsumfelds in Großunternehmen zusammen.

Was in kleinen Firmen kein Problem war, wird im Großunternehmen zu einem großen Problem

• Bei der Behebung von toolbezogenen Fehlern dauert es oft lange, die verantwortliche oder zuständige Person zu finden.
• Durch mangelnden Informationsaustausch innerhalb der Organisation und Wechsel der Zuständigkeiten entstehen Ineffizienz und Ressourcenverschwendung.
• Eine temporäre Lösung ist das Override lokaler Einstellungen, grundlegend handelt es sich jedoch um eine strukturelle Grenze der Organisation.

Irrationale Ressourcenverteilung

• Anders als in kleinen Firmen, in denen oft ohne ausreichendes Budget gearbeitet wird, kommt es in Großunternehmen häufig zu übermäßiger Ressourcenverschwendung.
• Gescheiterte kurzfristige Projekte oder unnötige Cloud-Nutzung führen zu finanzieller Verschwendung.
• Budget- und Ressourcenmanagement, das vom tatsächlichen Bedarf entkoppelt ist, senkt die Motivation bei der Arbeit.

Inkonsistente Kollegschaft und Einstellungsstruktur

• In Startups wahrt leistungsbasierte Einstellung vergleichsweise eher einen konsistenten Maßstab.
• In Großunternehmen sind Einstellung und Restrukturierung unabhängig von tatsächlicher Leistung oft üblich.
• Es kommt vor, dass bestimmte Positionen nichts mit der tatsächlichen Arbeitskompetenz zu tun haben oder Organisationen unabhängig von der Qualität ihrer Berichte fortbestehen.

Wie Dringlichkeit interpretiert wird

• In Startups gab es einen klaren Begriff von Dringlichkeit, während in Großunternehmen eine mehrschichtige Interpretation von Aufgaben notwendig ist.
• Neben echten dringenden Situationen (z. B. Service-Ausfällen) tritt häufig auch formale Dringlichkeit auf.
• In solchen Prozessen ist die Fähigkeit gefragt, die tatsächlichen Prioritäten der Arbeit zu erkennen.

Formalisiertes Sicherheitsmanagement

• Sicherheitsprozesse spielen in Organisationen eine wichtige Rolle, in der Praxis liegt der Fokus jedoch oft auf formaler Berichterstattung statt auf tatsächlichem Risiko.
• Sicherheitsarbeit, deren Bedeutung zugunsten von Zielwerten oder Kennzahlen verblasst, wird zum Alltag.
• Auch die Kommunikation zwischen Engineers und Sicherheitsverantwortlichen ist ineffizient.
• Hervorgehoben wird, dass eine Kultur, in der alle nur auf Zahlen schauen, riskant ist.

Die Bedeutungslosigkeit von Hierarchiestufen

• Doppelte Titel wie "Head of Architecture" sind verbreitet, obwohl die Rollen nicht klar definiert sind.

Eine Organisationskultur, die Unsicherheit als Schwäche betrachtet

• Inmitten großer organisatorischer Umbauten und häufiger Restrukturierungen gilt für Führungskräfte die Aussage „Ich weiß es nicht“ als tabu.
• Trotz der Komplexität der Domäne werden in der Führung vor allem Unmittelbarkeit und Selbstsicherheit priorisiert.
• Dadurch verfestigt sich eine Struktur, in der Fehler der Vergangenheit wiederholt werden.

Siloisierte Engineering-Teams

• Jedes Engineering-Team (oder „Imperium“) hat eigene Standards und eine eigene Kultur.
• Die Hürden zwischen Abteilungen wachsen, und Standardisierung sowie die Verbreitung von Best Practices werden erschwert.
• Die Autonomie der einzelnen Abteilungen wirkt als begrenzender Faktor für die teamübergreifende Zusammenarbeit.

Positive Erfahrungen

• Durch die Teilnahme an der Engineering-Community erweitert sich die Perspektive auf Softwareentwicklung.
• Es gibt neue Formen der Zufriedenheit, etwa durch Karrierewachstum, Mentoring-Möglichkeiten und Erfahrungen im großen Maßstab.
• Vertiefung der Fachlichkeit, Zusammenarbeit mit vielfältigen Kolleginnen und Kollegen sowie Weiterbildung und Kompetenzentwicklung werden aktiv gefördert.
• Auch Stabilität wie regelmäßige Gehaltszahlungen und Jobsicherheit wirkt als Vorteil.

Fazit

• Trotz der kritischen Perspektive ist der positive Wert von Großunternehmen klar erkennbar.
• Es besteht die Absicht, die eigene Sicht nach langer Zeit erneut zu überprüfen.

[GN⁺]

Hacker-News-Kommentare

• Man muss sich immer an Remy's Law of Enterprise Software erinnern (zugehöriger Link: https://thedailywtf.com/articles/graceful-depredations). Wenn Software als "enterprise" bezeichnet wird, ist sie meistens eher schlecht. Scherz beiseite: Die positiven Punkte, die am Ende des Artikels erwähnt wurden, fand ich interessant. Einige konnte ich nachvollziehen, aber es gab auch Punkte, die in der Praxis eher noch mehr Probleme zu schaffen scheinen. Zum Beispiel hieß es, es gebe "echte Möglichkeiten zur Karriereentwicklung". Wenn Karriereentwicklung einfach bedeutet, mehr Geld zu verdienen, dann sollte man doch einfach sagen: "Man kann mehr Geld verdienen" — dafür braucht es keine Umschreibung. Wenn nicht, frage ich mich, was Karriereentwicklung sonst sein soll, außer noch tiefer in die bereits beschriebenen organisatorischen Ineffizienzen und Probleme einzutauchen. Und bei "Es ist befriedigend, Software zu bauen, die von Millionen genutzt wird" frage ich mich ebenfalls, ob das immer noch befriedigend ist, wenn die Software schlecht ist oder den Nutzern schadet

  • Zu der Frage, ob Karriereentwicklung einfach nur bedeutet, mehr Geld zu verdienen: Wenn man lange genug über das Leben nachdenkt, wird man irgendwann mit der Realität konfrontiert, dass wir in einem viel größeren System nur eine kleine Rolle spielen. Daraus entstehen tiefere Fragen wie: „Kann ich in einer ungerechten Gesellschaft gerecht handeln?“ oder „Wie kann ich in meiner kleinen Rolle positiv auf die Gemeinschaft einwirken?“. Menschen gehen damit unterschiedlich um. Manche suchen aktiv nach Gelegenheiten, Veränderung zu bewirken, während andere sich innerhalb des Systems ohnmächtig fühlen und sich ganz davon abwenden. In meinem Fall glaube ich an das, was wir tun, und Karriereentwicklung im Unternehmen bedeutet für mich nicht einfach Geld, sondern mehr Verantwortung und mehr Fähigkeit, Veränderungen herbeizuführen. In einer ineffizienten Organisation kann ich entweder das Unternehmen verlassen, an meiner aktuellen Position bleiben oder tiefer in die Organisation hineingehen und positive Veränderungen schaffen. Auf die Frage „Ist es noch befriedigend, wenn die Software schlecht ist oder Schaden anrichtet?“ würde vielleicht mancher antworten, dass auch schädliche Arbeit befriedigend sein kann, aber ich gehöre zumindest nicht dazu und glaube, dass meine Arbeit gesellschaftlich etwas Gutes bewirkt. Gemeint ist also: „Es ist befriedigend, Software mit positivem gesellschaftlichem Nutzen zu bauen, die von Millionen verwendet wird“

  • Karriereentwicklung in Großunternehmen bedeutet mehr als nur Geld. Man bekommt zum Beispiel oft die Gelegenheit, Projekte in größerem Maßstab zu leiten oder ein Produkt vollständig intern zu entwickeln, das früher vielleicht ein ganzes Startup gebaut hätte. Erfahrungen über mehrere Jahre hinweg in verschiedenen Projekten zu sammeln oder größere Teams zu führen, ist in großen Unternehmen vergleichsweise leichter möglich. Und wenn die Software schlecht ist oder Schaden anrichtet? Startups und kleine Firmen sind nicht automatisch besser — das hängt vom Einzelfall ab

  • Wenn man von Rollen wie Data Scientist Researcher oder Developer Evangelist träumt, braucht man eine Organisation, die solche Tätigkeiten unterstützen kann. Rollen wie Microservices-Architekt passen ebenfalls nicht zu kleinen Organisationen, sind aber in Großunternehmen mit über 3000 Mitarbeitenden willkommen. Auch der Weg zum Engineering Manager ergibt erst Sinn, wenn der Talentpool groß genug ist — es gibt also Karriereentwicklungsmöglichkeiten, die aus der Größe entstehen. Es gibt zwar schlechte oder schädliche Software, aber das, woran wir arbeiten, muss nicht zwangsläufig Enterprise-Software sein, und ehrlich gesagt hoffe ich eher, dass es das nicht ist

  • Ich glaube nicht, dass Enterprise-Software ihrem Wesen nach schlecht ist. Natürlich kann man durchaus gute Enterprise-Software bauen, und das unter komplexen Anforderungen zu schaffen, ist an sich schon eine beachtliche Leistung. In der Praxis wird jedoch nur selten danach bewertet, wie sehr sich eine Organisation um die User Experience kümmert. Ich selbst war in über 7 Jahren bei $ENTERPRISE nur ein einziges Mal in direktem Kontakt mit Nutzern

  • Zur Frage, ob es befriedigend ist, auch wenn die Software schlecht ist oder schadet: Viele Ingenieure empfinden schon allein Zufriedenheit dabei, in großem Maßstab zu arbeiten, oder sie fühlen sich so ohnmächtig, dass sie die Sache als nicht ihre eigene betrachten. Denn um wirklich diese Größenordnung zu erreichen, muss man meist zu einem Tech-Giganten gehören, und damit landet man letztlich unweigerlich bei algorithmischen Dark Patterns, der Maximierung von Aktionärsinteressen und ähnlichen Strukturen des Kapitalismus

• Ein Punkt fehlt noch: Wenn neue Führungskräfte kommen, drängen sie oft die bisherigen Leute hinaus und besetzen alles mit ihren eigenen Leuten. Und jedes Jahr ändern sich die Teamnamen, obwohl sich an der tatsächlichen Arbeit nichts ändert — es werden nur immer wieder Wörter wie "Innovation", "Discovery" oder "Leadership" zum Teamnamen hinzugefügt

  • Wenn Teamnamen schon so oft geändert werden, würde ich lieber einfach dauerhaft unter einem Namen wie „Pikachu“ arbeiten. Wenn allen klar wäre, dass der Name egal ist, würde dieses ständige Umbenennen vielleicht aufhören. Jedes Mal müssen Dokumente angepasst und alle informiert werden, was unnötig viel Mühe und Zeit kostet

  • In unserer Organisation gibt es eine interne Infrastruktur-Code-Bibliothek auf Basis von Terraform CDK. Sie erstellt automatisch Monitoring-Ressourcen in Datadog und Pagerduty. Eines Tages habe ich den Pflichtparameter team einfach entfernt, weil er faktisch ohnehin alle sieben Monate wechselte

  • Mein Rivale bringt, wann immer er in ein neues Unternehmen eintritt, nach und nach sein komplettes früheres Helpdesk- und Entwicklerteam mit. Der Grund ist Loyalität. Selbst wenn die Ergebnisse schlecht sind, gibt es keine Beschwerden, und Probleme werden nicht nach oben eskaliert. Wenn man mit ehemaligen Mitarbeitenden spricht, die unter dieser Person gearbeitet haben, hört man immer dieselbe Geschichte:

    1. Problem diagnostizieren (es heißt dann, das Problem sei das Fehlen eines neuen Microsoft-Partner-CRMs)
    2. Geld zur Problemlösung ausgeben (dank dieses CRM-Partners und Microsoft gibt es dann drei Geschäftsreisen pro Jahr nach Las Vegas)
    3. Einführung des CRM scheitert (behauptet wird, das Problem sei gewesen, dass der Scope nicht groß genug war)
    4. Projektumfang erneut anpassen (mit noch mehr Zusatzleistungen)
    5. Kurz vor dem nächsten Scheitern in ein neues Unternehmen wechseln und im alten nur Probleme zurücklassen

  • Wenn ein Projektname Wörter wie „Excellence“ enthält, weckt das bei mir meistens kein Vertrauen

• Das meiste aus dem Artikel trifft auch auf den öffentlichen Sektor zu. Mit Ausnahme dessen, dass es keine Wochenendarbeit gibt, dass es Möglichkeiten zur (technischen) Karriereentwicklung gibt und dass Kompetenzaufbau oder Weiterbildung gefördert werden, ist es sehr ähnlich

  • Auch die eingangs erwähnte Freude und der finanzielle Vorteil scheinen auf den öffentlichen Sektor nicht besonders zuzutreffen

• Sehr unterhaltsamer und interessanter Artikel. Ich arbeite seit etwa drei Jahren im Enterprise-Umfeld. Technisch wachse ich zwar, aber tatsächlich lerne ich noch mehr über Menschen, Kommunikation und Bürokratie. Die Kommentare zum Budget und zur Maus konnte ich gut nachvollziehen. Dank der finanziellen Stabilität von $ENTERPRISE kaufe ich mir die Maus einfach selbst. Jemand könnte das Fehlen einer Genehmigung für die Maus problematisieren, aber ... ich ignoriere das dann einfach oder tue diese künstliche Dringlichkeit einer Mausfreigabe als unwichtig ab

• In solchen Organisationen könnte ich es unmöglich aushalten. Selbst wenn sie das Dreifache zahlen würden, wäre ich nach ein paar Monaten völlig am Ende

  • Die Entschädigung steht tatsächlich in umgekehrtem Verhältnis zur Menge der Arbeit, die wirklich nötig ist

  • Ich müsste schon eine sehr hohe Dosis Psychopharmaka (Zoloft) nehmen, um das überhaupt auszuhalten

  • Manchmal überlege ich, das Geld zur Priorität zu machen, bei $ENTERPRISE ein hohes Gehalt mitzunehmen, genug anzusparen und dann ein langes Sabbatical zu machen. Aber schon die Vorstellung des Bewerbungsprozesses ist so anstrengend, dass mir sofort die Motivation vergeht. Im Moment bin ich bei $MIDSIZENOLONGERSTARTUP, und auch dort gibt es auf ganz eigene Weise viele merkwürdige Dinge, die mich auslaugen

• Ich arbeite ebenfalls in einem ähnlichen Umfeld, und dieser Text fühlte sich schmerzhaft präzise an. Ich dachte, meine Arbeit bestehe darin, Probleme zu lösen und Software auszuliefern, aber in der Realität sind das überhaupt nicht die „echten Prioritäten“ der Organisation (revealed preferences, zugehöriger Link: https://en.wikipedia.org/wiki/Revealed_preference). Wie in der Geschichte des Autors über den Wechsel von einem kleinen Unternehmen in einen Konzern frage ich mich, ob hier jemand den umgekehrten Weg gegangen ist — also vom Großunternehmen in eine kleine Firma. Mich würde auch interessieren, wie man Enterprise-Erfahrung in Interviews mit kleinen Teams gut verkaufen kann

  • Meiner Erfahrung nach ist das wie eine Geschichte aus zwei Städten. Auch ich bin die sinnlose Zeitverschwendung bei $ENTERPRISE leid und würde inzwischen sogar 20 % Gehalt aufgeben, um an einem kleineren, vernünftigen Ort tatsächlich etwas zu erreichen. Aber selbst wenn ich versuche, das in den letzten drei Jahren Gelernte ohne negative Stimmung zu erklären, sehen Startup-Gründer meinen Werdegang eher als Belastung. Die Überlebensfähigkeiten, die man im Dschungel braucht, unterscheiden sich zu stark von denen, die man im Zoo braucht, und die Reaktion ist dann oft: Warst du vielleicht zu lange im Zoo? Umgekehrt wollen auch Großunternehmen Menschen einstellen, die ihre internen Prozesse und Hierarchien verstehen, weshalb es auch für Leute aus Startups nicht leicht ist, sich dort zu bewerben

  • Ich habe den Wechsel von einem großen in ein kleines Unternehmen gemacht, und je größer ein Unternehmen wird, desto mehr drehen sich die zu lösenden Probleme um Menschen und interne Politik statt um technische Fragen. In Großunternehmen werden Schlüsselkräfte oft mit einer Art Golden Handcuffs gebunden (zugehöriger Link: https://en.wikipedia.org/wiki/Golden_handcuffs), weshalb die Leute all den organisatorischen Unsinn länger ertragen, bis sie bereit sind, auf diese Vergütung zu verzichten. Wenn man die Geschichte als „Ich wollte das Großunternehmen verlassen und wieder echte Veränderungen bewirken“ erzählt, wird das in kleinen Teams meist gut verstanden

• Großunternehmen achten nur darauf, ihre jeweilige Art von Ergebnissen konsistent zu liefern. Ziele werden aus ganz unterschiedlichen Gründen gesetzt — um Zahlen zu erreichen, regulatorische Verfahren zu erfüllen oder Entscheidungen von Führungskräften umzusetzen. Das ist eine völlig andere Sphäre als die menschliche Rationalität, die wir uns normalerweise vorstellen

• Zum ursprünglichen Text mit den „anderen Imperien“ noch ein Scherz: Neben Großbritannien (manuelles QA) und Ägypten (Software-Pyramiden) gäbe es auch die Mongolei (wirft eines Tages plötzlich einen Berg von Anforderungen hinein und verschwindet dann wieder), Spanien (will alle Regeln perfekt machen und erzeugt dadurch nur noch mehr Reibung), Japan (wird von Führungskräften zurechtgewiesen und begeht ein karriereschädigendes Himmelfahrtskommando) und China (verirrt sich in einem Labyrinth aus Meetings, während die Kommunikation extrem verschlossen bleibt)

  • Ich hatte wirklich Spaß beim Lesen dieses Textes, besonders die Kriegsmetapher mit der Mongolei war lustig. Tatsächlich waren Kämpfe gegen die Mongolen historisch gesehen auch alles andere als einfach

• Guter Einblick und ein Text, der die Bedeutung von Büropolitik und der Rolle des Managements gut vermittelt

• Ich bin seit 18 Monaten bei $ENTERPRISE. Das trifft die Realität so genau, dass es fast weh tut