- Ein Beitrag mit praktischen Strategien dazu, wie Ingenieure sich in Tech-Unternehmen wirksam an Organisationspolitik beteiligen können, und wie sich das Gefühl politischer Ohnmacht überwinden lässt, das viele Ingenieure haben
- Ingenieure sind keine Spieler im politischen Machtspiel, sondern Werkzeuge; dennoch können sie politischen Einfluss ausüben, indem sie den Erfolg von Projekten mit hoher Sichtbarkeit aktiv unterstützen oder technische Ideen passend zu veränderten organisatorischen Prioritäten vorschlagen
- Da sich die Interessen einer Organisation wie Wellen verändern, besteht eine Schlüsselstrategie darin, technische Programme in verschiedene Richtungen wie Stabilität, Developer Experience und Performance-Verbesserungen im Voraus vorzubereiten und sie zum richtigen Zeitpunkt vorzuschlagen
- Wenn politische Notwendigkeiten und das Fehlen guter Ideen aufeinanderprallen, entstehen die schlechtesten technischen Entscheidungen; Senior Engineers haben die Verantwortung, zur richtigen Zeit die richtigen Ideen einzubringen
- Zynisch betrachtet bedeutet das, sich zum Werkzeug in Machtkämpfen zu machen; optimistisch betrachtet ist es ein Weg, die Prioritätensetzung des Managements zu respektieren und gleichzeitig die eigenen technischen Ziele zu erreichen
Der verbreitete Glaube an die politische Ohnmacht von Ingenieuren
- Viele Software Engineers haben gegenüber Firmenpolitik eine fatalistische Haltung und glauben, Beteiligung sei sinnlos
- Technische Entscheidungen werden oft aus völlig eigennützigen Gründen getroffen, sodass gutwillige Ingenieure keinen Einfluss nehmen können
- Mächtige Stakeholder sind zu inkompetent und dysfunktional, um ihre Anforderungen überhaupt sinnvoll zu verstehen und Lösungen dafür bereitzustellen
- Das politische Spiel beruht auf nicht öffentlichen Informationen, über die Ingenieure nicht verfügen; Beteiligungsversuche führen daher nur zu hilflosem Herumstochern
- Manager und Führungskräfte verbringen den Großteil ihrer Zeit mit Politik, während Ingenieure an Engineering arbeiten; deshalb starten Ingenieure mit einem erheblichen politischen Nachteil
- Es stimmt, dass Software Engineers nicht auf demselben Niveau spielen können wie die eigentlichen politischen Akteure
- Wenn Ingenieure anfangen, Intrigen wie in Game of Thrones zu spinnen, ist das ein schrecklicher Fehler; solche Manöver werden sofort durchschaut und gegen sie verwendet
- Für Intrigen braucht man Übung und Macht, und beides fehlt Software Engineers in der Regel
Praktische Wege zur politischen Beteiligung
- In großen Unternehmen sind Software Engineers im politischen Spiel zwar schlicht Werkzeuge statt Spieler, aber es gibt dennoch viele Möglichkeiten, sich ohne Intrigen politisch einzubringen
- Der einfachste Weg ist, aktiv am Erfolg eines Projekts mit hoher Sichtbarkeit zu arbeiten
- Das ist fast identisch mit dem, was man ohnehin als Teil der normalen Arbeit tun sollte
- Wenn das Unternehmen stark in ein neues Projekt investiert — derzeit oft ein AI-Projekt — dann ist es ein politisch kluger Zug, die eigenen Engineering-Fähigkeiten dafür einzusetzen, dieses Projekt erfolgreich zu machen, weil das dem VP oder Executive hilft, der es vorantreibt
- Im Gegenzug erhält man Belohnungen, die Executives in Tech-Unternehmen vergeben können: Boni, Unterstützung bei Beförderungen oder Rollen in zukünftigen Projekten mit hoher Sichtbarkeit
Technische Ideen für politische Kampagnen nutzbar machen
- Ein etwas schwierigerer, aber kontrollierbarer Weg ist, die eigenen bevorzugten Ideen für eine bestehende politische Kampagne nutzbar zu machen
- Wenn man zum Beispiel bestehende Funktionen in einen separaten Service auslagern möchte, gibt es zwei Wege
- Der schwierige Weg: eigenes politisches Kapital einsetzen, Unterstützung aufbauen, dem Management die Wichtigkeit vermitteln und Skeptiker langsam überzeugen, bis das Projekt genehmigt wird
- Der leichte Weg: zulassen, dass ein Executive sein eigenes, viel größeres politisches Kapital für das Projekt einsetzt
- Man wartet, bis es eine unternehmensweite Vorgabe für ein Ziel gibt, das zum Projekt passt, etwa ein verstärkter Fokus auf Stabilität nach einem größeren Vorfall
- Dann schlägt man dem Management vor, dass das eigene Projekt dazu passen könnte
- Wenn die Einschätzung richtig war, unterstützt die Organisation das Projekt, und statt politisches Kapital zu verbrauchen, vergrößert man es sogar
Auf den Wellen der Organisationsinteressen reiten
- Das Interesse einer Organisation kommt in Wellen
- In Phasen, in denen Stabilität im Fokus steht, sind VPs verzweifelt darauf angewiesen, irgendetwas zu tun, und suchen nach plausiblen Stabilitätsprojekten, die sie ihren Vorgesetzten präsentieren können, ohne selbst die Fähigkeit zu haben, solche Projekte zu entwickeln
- Sie sind in der Regel bereit, nahezu alles zu finanzieren, was ein Engineering-Team dazu vorschlägt
- Wenn die Aufmerksamkeit der Organisation dagegen auf etwas anderem liegt, etwa einem großen Produktlaunch, möchte niemand, dass Engineers Zeit mit internem, für Kunden unsichtbarem, auf Stabilität ausgerichtetem Refactoring verbringen
- Um in einem Tech-Unternehmen technische Arbeit umzusetzen, muss man auf die richtige Welle warten
- Es ist eine gute Idee, technische Programme in mehreren unterschiedlichen Richtungen im Voraus vorzubereiten
- Starke Engineers stoßen im normalen Arbeitsalltag automatisch auf solche Möglichkeiten
- Beispielpläne:
- Billing-Code von gecachten API-Aufrufen auf gespeicherte Daten migrieren, die per Webhooks aktualisiert werden
- Eine alte handgebaute Build-Pipeline abschaffen und durch Vite ersetzen
- Einen stark frequentierten, unübersichtlichen Python-Service in Golang neu schreiben
- Ein langsames CMS-Frontend für öffentliche Dokumentation durch eine schnelle statische Website ersetzen
Warum der richtige Zeitpunkt für Vorschläge entscheidend ist
- Wenn Executives sich Sorgen um Billing machen, kann man ein Billing-Refactoring als Stabilitätsverbesserung vorschlagen
- Wenn sie sich um die Developer Experience sorgen, kann man den Austausch der Build-Pipeline vorschlagen
- Wenn Kunden sich über Performance beschweren, kann man ein Rewriting in Golang als gute Option präsentieren
- Wenn der CEO den Zustand der öffentlichen Dokumentation prüft und erschrickt, kann man den Neuaufbau als statische Website vertreten
- Wichtig ist, für jeden Hype des Monats ein detailliertes und wirksames Arbeitsprogramm bereit zu haben, das sofort umsetzbar ist
Der Moment, in dem die schlechtesten technischen Entscheidungen entstehen
- Auch ohne diesen Ansatz werden manche Programme finanziert, aber ohne ihn hat man keine Kontrolle darüber, welche Programme das sein werden
- Hier treffen Unternehmen die schlechtesten technischen Entscheidungen: wenn die politische Notwendigkeit, etwas zu tun, auf das Fehlen guter Ideen stößt
- Wenn keine guten Ideen vorhanden sind, werden eben schlechte verwendet — obwohl niemand dieses Ergebnis bevorzugt
- Schlecht für Executives: Sie müssen enttäuschende technische Ergebnisse als Erfolg verkaufen
- Schlecht für Engineers: Sie müssen Zeit und Energie darauf verwenden, die falsche Idee umzusetzen
- Wenn man sehr Senior ist und VPs einen dafür stillschweigend verantwortlich machen, dann haben sie damit recht
- Es ist deine Verantwortung, die richtige Idee zum richtigen Zeitpunkt bereitzuhalten
Zwei Perspektiven
- Die zynische Perspektive: Man kann das als Aufforderung lesen, sich für die Soziopathen, die das Unternehmen führen, zum nützlichen Werkzeug in endlosen internen Machtkämpfen zu machen
- Die optimistische Perspektive: Man kann es als Aufforderung lesen, den Executives die übergreifenden Prioritäten des Unternehmens setzen zu lassen — denn das ist ihr Job — und die eigenen technischen Pläne daran auszurichten
- In jedem Fall kann man mehr technische Ziele erreichen, wenn man den richtigen Plan zum richtigen Zeitpunkt vorantreibt
Reaktionen auf Hacker News und zugehörige Zitate
- Der Beitrag erhielt auf Hacker News Aufmerksamkeit und deutlich positivere Reaktionen als viele andere Texte über Politik
- Ein Kommentar verwies auf ein Zitat von Milton Friedman und übertrug die Idee des Artikels auf allgemeine politische Entscheidungsfindung
- "Nur eine Krise — ob real oder wahrgenommen — erzeugt wirkliche Veränderung. Wenn diese Krise eintritt, hängen die ergriffenen Maßnahmen von den Ideen ab, die gerade verfügbar sind. Das ist unsere grundlegende Funktion: Alternativen zu bestehenden Richtlinien zu entwickeln und sie lebendig und verfügbar zu halten, bis das politisch Unmögliche politisch unvermeidlich wird"
- Einige Kommentare kritisierten diesen Ansatz als zu spielerisch und eigennützig, doch der Autor meint, das hänge von den Zielen ab
- Ein Kommentar fasst die Kernaussage gut zusammen: "Anstatt auf Anweisungen zu warten, bei Lücken zynisch über schlechte Ideen zu sein und nicht das zu tun, was man eigentlich will, pflegt der Autor einen Backlog guter und wichtiger Ideen, die eingebracht werden können, wenn eine wichtige Person sagt, dass etwas Priorität hat. Er geht beim Timing Kompromisse ein und setzt so trotzdem das um, was er erreichen will"
1 Kommentare
Hacker-News-Kommentar
Der Kern dieses Beitrags ist folgender
Der erste Punkt klingt vielleicht selbstverständlich, aber ich habe dazu viele Leute in frühen Karrierephasen immer wieder gecoacht Bei vielen, die Schwierigkeiten hatten oder auf eine PIP zusteuerten, war genau diese Schleife der Wendepunkt
Ich verstehe Punkt 2 als Vorbereitung einer eigenen Agenda. Wenn ich zum Beispiel die Codebase minimalistischer machen möchte, bereite ich einen PoC und die relevanten Details so vor, dass ich den Vorschlag sofort einbringen kann, sobald sich eine Gelegenheit ergibt Wenn dann dank dieser Vorbereitung Probleme mit Site-Performance, SEO oder Bugs auftreten, kann ich die Minimalismus-Idee als Lösung vorschlagen Das Konzept finde ich spannend, aber ich frage mich oft, wie man es konkret anwenden kann. Ich überlege auch häufig, ob ich Vorbereitungsdokumente für die Zukunft anlegen sollte. So ähnlich, als würde ich wie bei einem Blog meine Arbeit laufend dokumentieren und auf eine Gelegenheit warten Viel zusätzliche Arbeit kann am Ende verpuffen, aber ehrlich gesagt mache ich ohnehin schon vieles davon
Ich würde noch ergänzen, dass man nichts leichtfertig tun sollte, woran Leute Anstoß nehmen, die politisch mächtiger sind als der eigene Manager. Eine Ausnahme ist natürlich, wenn jemand, der noch mächtiger ist, es offen anordnet Es geht nicht darum, unbedingt zu tun, was diese Leute wollen, sondern darauf zu achten, sie nicht unnötig zu verärgern Es lohnt sich fast nie, Feinde zu machen, und die meisten Manager machen in Krisenlagen zur eigenen Absicherung auch schnell andere zum Sündenbock
Ich bevorzuge es, meinem Manager direkt vorzuschlagen, „was getan werden sollte“. Ich bringe wichtige Themen auf den Tisch und argumentiere, warum sie wichtig sind Man sollte proaktiv dafür sorgen, dass der Manager von der eigenen Expertise profitiert Ich habe damit selbst noch nicht riesig viel Erfahrung, aber einige erfolgreiche Fälle gab es schon
Dieser Rat wird umso wichtiger, je weiter man aufsteigt. Das gilt auch für Engineering Manager, und selbst als Director, der direkt an den CTO berichtet hat, habe ich versucht, nach diesem Prinzip zu handeln
Eines meiner Lieblingszitate lautet: "Nur eine tatsächliche oder wahrgenommene Krise erzeugt wirkliche Veränderung. Welche Maßnahmen dann ergriffen werden, hängt von den Ideen ab, die gerade in der Umgebung zirkulieren. Unsere Grundfunktion ist es, alternative Konzepte zu entwickeln und am Leben zu halten, bis das politisch Unmögliche politisch unvermeidbar wird" – Milton Friedman Für mich war es wirksam, 1-Pager und technische Dokumente im Voraus zu schreiben, zu teilen und sie dann in der Krise wieder aufzugreifen, um meine Ideen voranzubringen Ich habe mich so schrittweise in die gewünschte Architektur-Richtung bewegt und mich Stück für Stück meinem Ziel angenähert; entscheidend war dabei, Konsens aufzubauen Natürlich wurde ich auch oft von VPs oder Directors ausgestochen, die politisch geschickter waren als ich Aber es war deutlich wirksamer, eine Bibliothek von 1-Pagern bereitzuhalten, sie nebenbei zu teilen, sie gewissermaßen in der Luft zirkulieren zu lassen und dann zu warten, bis eine Motivation zur Umsetzung entsteht
Mit dem Teil „Ich habe den politischen Kampf verloren“ kann ich mich identifizieren. Eine überraschende Erkenntnis, seit ich mindestens im mittleren Management bin, ist, wie sichtbar politische Spielchen auf unteren Ebenen sind Viele ICs oder EMs der ersten Ebene überschätzen ihr politisches Gespür oder ihren sozialen IQ Dazu kommt, dass Tiefe und Breite der Kommunikation in einer Organisation anders aussehen, sodass jemand vielleicht glaubt, er überzeuge einen Stakeholder, dieser aber nach dem Gespräch dem Vorgesetzten nebenbei den Kontext steckt Wir haben solche Szenen mehrfach beobachtet, während wir im Management-Team versucht haben, plumpes Taktieren leise einzudämmen
Mich würde interessieren, was ganz konkret damit gemeint ist, 1-Pager und technische Dokumente „zirkulieren zu lassen“
Ich stimme dem Zitat zu und glaube, dass diese Methode wirken kann. In der Realität ist die Zeitskala aber oft absurd lang, sodass man daran zermürben kann Außerdem werden Krisen häufig komplett ignoriert, also gar nicht als solche wahrgenommen oder schlicht normalisiert
Mich würde interessieren, ob dir die 1-Pager auch Anerkennung und Beförderungen gebracht haben oder ob sie vor allem dabei geholfen haben, Ideen tatsächlich umzusetzen
Das ist aus meiner Sicht der beste Weg
Häufig in Produktion deployen (also auf reale Lieferung statt theoretische Arbeit setzen)
Aussagekräftige Ergebnisse erzielen (
wins) anhand vereinbarter MetrikenJemanden im Management oder unter den PMs haben, der meine Erfolge gut „verkaufen“ kann Trotzdem treten weiter Probleme auf. Es gibt immer einen neuen VP oder Leader, der Innovation demonstrieren will. Teams, die bestehende Systeme warten, werden schnell als falsch abgestempelt, und der neue VP betont mit progressiven Ideen wie AI seine eigene Linie. In dem Moment, in dem mein Code ausgerollt ist, gilt er schon als „Legacy“ Dann verteilt der VP große Versprechen über eine glänzende Zukunft, und mit meiner Rolle, die die Gegenwart am Laufen hält, kann ich damit nie konkurrieren. Die Realität ist weder sexy noch spannend. So wird man zur alten Garde Im Kern geht es am Ende um Protektion und Patronage: den VP über dir erfolgreich machen und sich eine Position schaffen, in der man mitgeht, wenn diese Person weiterzieht
Ich halte das für sehr wahr. Noch einen Schritt weiter gedacht ist es als Staff Engineer wichtig, klar zu vermitteln: „Ich bin nicht der Code selbst.“ Code ist ab dem Moment des Deployments Schuld/Legacy Im Idealfall positioniere ich mich nicht als „Verteidiger des Codes“, sondern als EQUAL PARTNER von Leadership, Produkt und Entscheidungsträgern. Das ist letztlich eine Frage des Framings. Selbst wenn ich dasselbe tue: Wenn ich als Partner in der Arbeit wahrgenommen werde, sehen mich Führungskräfte als proaktiven Helfer; andernfalls gelte ich als Hindernis, das man mühsam überzeugen muss. Das macht einen großen Unterschied
Der Punkt „Man braucht unter den PMs jemanden, der die eigene Leistung gut verkauft“ trifft für mich völlig zu. Rückblickend war wahrscheinlich einer der größten Hebel in meiner Karriere, wie schnell ich mich von schlechten PMs lösen konnte Gute PMs machen alles besser, sind aber schwer zu finden. Umgekehrt zerfällt alles, wenn ein PM die Richtung nicht im Griff hat, und sobald genau dieser PM weg war, änderte sich die Stimmung oft schlagartig
Die Formulierung „Man kann mit Zukunftsversprechen nicht konkurrieren“ fand ich großartig. So etwas passiert viel zu oft. Selbst wenn dieses Versprechen schon 26 Mal zuvor nicht eingehalten wurde, ist die „glorreiche Zukunft“ immer wieder beeindruckend
Beim tatsächlichen Arbeiten finde ich die Idee des häufigen Deployens gut (
rep= Ausführung statt Theorie), aber ich frage mich, warum die vagen Zukunftsversprechen eines VP oft höher bewertet werden als UmsetzbarkeitDen Ausdruck „theoretische Arbeit“ habe ich noch nie gehört, aber es gibt definitiv Orte, an denen täglich deployed wird. Ich halte häufiges Deployen aber nicht für ideal. Wie soll man in einem einzigen Tag etwas Substanzielles deployen? Projekte wie bei mir, die dem Unternehmen zusätzlichen Umsatz bringen, lassen sich nicht in einem Tag abschließen. Wenn eine Aufgabe an einem Tag erledigt wäre, bräuchte man denselben Engineer praktisch nur viermal im Jahr. Deshalb ist dieses „häufig deployen“ eher eine Vanity Metric
Ich habe wohl noch nie in einem dysfunktionalen Unternehmen gearbeitet, deshalb kann ich mit dem ersten Teil dieses Textes überhaupt nichts anfangen In meiner Erfahrung gab es immer starke Top-down-Kommunikation, und selbst wenn in eine Richtung entwickelt wurde, mit der ich nicht einverstanden war, wurde das vorher ausreichend diskutiert, sodass es interessant war zu verstehen, warum kluge Kolleginnen und Kollegen etwas anders sahen als ich Vielleicht liegt es daran, dass ich nur in von Engineers gegründeten Unternehmen gearbeitet habe, oder ich hatte einfach Glück
In großen Unternehmen haben VPs auf höherer Ebene breitere Ziele und auch ein breiteres Verständnis von Mitteln. Das ist nicht nur schlecht. Man bekommt die Chance, mehrere Optionen auszuprobieren, bevor man sich auf eine bestimmte Technologie oder Methodik festlegt. Natürlich ist das verschwenderisch, aber es kann auch effizient sein, um schnell auf tektonische Verschiebungen in der Branche zu reagieren und die Ziele des Managements zu erfüllen
Mich würde interessieren, in Unternehmen welcher Größe du gearbeitet hast
„Ein etwas schwierigerer Weg, aber einer mit mehr Kontrolle, ist, meine Idee an eine bestehende politische Kampagne anzudocken“ Ich habe gelernt, mich geschickt an Projekte anzuhängen, die von einem VP vorangetrieben werden. Es ist bitter, aber sehr wirksam
In diesem Lager hört man oft Frust wie: „Ich habe den gesamten Code perfekt refaktoriert, und niemand erkennt das an“ Ein früherer Bekannter erzählte einmal stolz, er habe monatelang eine Datenpipeline perfekt aufgeräumt, aber niemand habe den Wert darin gesehen; das hat mich zu einigen Gedanken gebracht Als Engineer sehe ich natürlich den Wert solcher Arbeit, aber aus PM-/EM-Sicht ist das ungefähr so, als würde ein PM einen Monat lang alle internen Engineering-Dokumente punktgenau sortieren und die Reaktion wäre: „Und was hat das jetzt fürs Unternehmen gebracht?“ Aus PM-Sicht wird es dadurch schwer, zwischen einem Engineer mit echter Wirkung und einem Engineer zu unterscheiden, der nur „Formatierungsarbeit“ macht Deshalb ist es entscheidend, geplante Arbeit vorab in einem Format klar zu erklären, das für ein nichttechnisches Publikum passt Ich habe früher versucht, Unit-Tests und Integrationstests voranzubringen, aber weil der politische Wille fehlte, landete das nie weit oben auf der Prioritätenliste. Erst als tatsächlich ein großer SEV auftrat und ich sagte: „Um so etwas zu verhindern, brauchen wir Tests“, waren plötzlich alle vom Wert überzeugt. Inzwischen versteht das jeder
Stimme ich völlig zu. Wenn ich etwas als Priorität voranbringen will, muss ich es in der Logik und Sprache derjenigen erklären, die Prioritäten festlegen PMs denken zum Beispiel üblicherweise in Geldwerten. Wenn ich mein technisches Ziel – etwa mehr Testabdeckung – so darstellen kann, dass es pro Jahr 200 Developer-Stunden kostet, aber 400 Developer-Stunden spart, Support-Tickets um 15 % senkt oder künftige Business-Szenarien ermöglicht, ist Überzeugungsarbeit viel leichter Ein Trick, den ich mag, ist, Tech-Debt-Arbeit nicht als „technische Arbeit“ zu verkaufen, sondern mit einem klaren Business-Effekt zu verpacken, sodass der PM sie am Ende selbst in die Roadmap aufnehmen will Mit zunehmender Erfahrung wird das leichter. Anfangs sind Leute vielleicht skeptisch, aber mit der Zeit bauen sich Vertrauen in meine Schätzungen und meine Ergebnisse auf, und Dinge, für die früher mehrere Meetings nötig waren, lassen sich heute in einem zehnminütigen Gespräch klären
Ich stimme dem ebenfalls zu. Aber man kann es auch umgekehrt betrachten Wenn auf einer Baustelle jemand Sicherheitssysteme sorgfältig prüft und wartet und dadurch Unfälle verhindert, erkennen Management-Teams diesen Wert oft trotzdem nicht an und belohnen ihn nicht Dass ein Nutzen nur dann zählt, wenn er sich quantitativ als ROI darstellen lässt, ist an sich schon ein enormes Versagen von Management – und wenn Sicherheit direkt mit Menschenleben zu tun hat, sogar ein moralisches Versagen Genau das ist in gewisser Weise die Realität bei Boeing
Der entscheidende Punkt ist, den Wert so zu erklären, dass das Publikum ihn versteht. Das ist letztlich eine Sales-Skill, und ich glaube, den meisten Developern fehlt dafür entweder die Erfahrung oder überhaupt das Bewusstsein. Ideal ist es, wenn ein guter Manager das aktiv unterstützt und wenn ein Staff Dev oder Engineering Manager mit ähnlichem Mindset mitzieht; dann hat das enormen Effekt Ich bin bei solchen Kolleginnen und Kollegen immer dankbar für die Zusammenarbeit
Wenn man überhaupt erklären muss, warum Händewaschen nötig ist, um dafür Investitionen zu bekommen, stimmt im Team etwas nicht. So wie ein Spitzenkoch in einem Top-Restaurant nicht erst überzeugen muss, ob man Seife kaufen sollte, ist es schon ein Karriereschritt, in eine Organisation zu kommen, in der solche Dinge selbstverständlich sind. Erfolgreiche SWEs arbeiten in Teams, in denen dieses Niveau Basisstandard ist
Stimme zu. Refactoring gehört ganz natürlich zur Verantwortung von Developern. Wenn man es bei der Feature-Entwicklung einfach mit erledigt und den Zeitplan entsprechend aktualisiert, muss man das nur mit anderen Technikerinnen und Technikern abstimmen; dadurch ist Überzeugungsarbeit viel einfacher, und langfristig verbessert sich die Qualität der Codebase stark Das macht die Wartung leichter und beschleunigt die Entwicklung neuer Features
Das größte politische Kapital, das ich aufbauen kann, ist mein technisches Verständnis und meine Fähigkeit. Aber diese Macht ist nur dann nützlich, wenn ich innerhalb der Gesamtstrategie und des Kontexts des Unternehmens berate und tatsächlich liefere Wenn ich guten Rat gebe und im Sinne des Unternehmens handle, hören die Leute auf mich und verlassen sich auf mich. Daraus entsteht letztlich die Befugnis, die Richtung mitzubestimmen Einen separaten Plan B oder eine Risikomitigation vorzubereiten und ihn dann bei Bedarf vorzuschlagen und umzusetzen, ist der beste Weg
Es gibt ein ziemlich radikales, aber in Teilen treffendes Karrierbuch Einer der Gedanken darin ist, dass technische Kompetenz der eigenen Karriere und Macht sogar schaden kann. Wenn ich meine Zeit und Energie darauf verwende, tatsächlich etwas zu tun, dann wird ein fähiger Manager aktiv versuchen, mich auf meiner Position festzuhalten, damit ich möglichst wenig politischen Einfluss gewinne Wenn ich dagegen Manager werde, sollte ich selbst möglichst nichts konkret tun, sondern so viele Initiativen (Projekte, Richtlinien, Veränderungen) wie möglich anstoßen und meine politische Macht geschickt orchestrieren Ob diese Initiativen tatsächlich Wert schaffen, ist nicht wichtig und muss mich auch gar nicht kümmern. Ich bin dann schon weitergezogen, während die Leute, die sich immer noch an Erfolg und Wertschöpfung festklammern und tatsächlich arbeiten, zurückbleiben Falls nötig, kann ein Manager sich hinterher einfach den Credit nehmen
Meine politische Theorie lautet: Es braucht Teams, deren Aufgabe es ist, sich auf das jeweilige „Flavor of the month“ einzustellen – sonst bewegt sich nichts. In Washington, D.C. ist es genauso. Es gibt keinen großen Masterplan, sondern immer einsatzbereite Truppen, die sofort pitchen, sobald sich eine Gelegenheit ergibt
Wenn man politische Kämpfe trainieren und Macht aufbauen muss, sollte man sich ein neues Unternehmen suchen Vielleicht hält man mich für naiv, aber nicht alle Firmen sind so. Meine ist es nicht