So legt ihr Gehaltsbänder für ein verteiltes Engineering-Team in Europa fest

Wählt ein Modell, schreibt die Regel auf und wendet sie bei jeder Person gleich an. Die drei realistischen Optionen sind ein einheitlicher Satz fürs ganze Team, ein Ankergehalt, angepasst über einen veröffentlichten Standortfaktor, oder ein separates Band pro Markt. Alle drei funktionieren. Was ein verteiltes Team zerbricht, ist ein unterschiedlicher Ansatz pro Einstellung — zwei Engineers auf derselben Stufe, die eine beträchtliche Lücke entdecken, die keiner von beiden erklären kann.

Im Folgenden geht es darum, wie sich jedes Modell in der Praxis über europäische Märkte hinweg verhält, woher ihr Zahlen bekommt, die ihr verteidigen könnt, und welche Entscheidungen sich erst nach achtzehn Monaten zeigen.

Entscheidet über die Stufe, bevor ihr über das Geld entscheidet

Wenn ihr kein Leveling-Framework habt, sind Gehaltsbänder nur eine Liste von Zahlen, über die ihr streiten werdet. Ihr braucht vier bis sechs Engineering-Stufen mit schriftlich festgehaltenen Erwartungen — Arbeitsumfang, wie viel Aufsicht, wofür die Person verantwortlich ist —, bevor irgendein Band überhaupt etwas bedeutet.

Das spielt in einem verteilten Team eine größere Rolle als in einem Team an einem Standort. Wenn alle in einem Büro sitzen, wird die Stufe informell kalibriert: Man sieht, wer was macht. Wenn eure Senior Engineers in Warschau, Lissabon und Istanbul sitzen und euer Hiring Manager in Amsterdam ist, verschiebt sich „Senior“. Märkte haben unterschiedliche Titelinflation. Ein Titel, der in einem Markt Jahre echter Verantwortung bedeutet, kann in einem anderen eine Beförderung sein, die anstelle einer Gehaltserhöhung vergeben wurde. Wenn ihr die Bezahlung an Titel aus den Lebensläufen von Kandidat:innen koppelt, importiert ihr diese Verschiebung direkt in eure Gehaltsabrechnung.

Also: Definiert Stufen über Verhaltensweisen, kalibriert Neueinstellungen gegen Engineers, die ihr bereits habt, und schaut erst danach auf eine Zahl.

Die drei Modelle, und was euch jedes davon kostet

Ein globaler Satz. Alle auf einer bestimmten Stufe verdienen dasselbe, meist orientiert an einem teuren Markt. Das ist die am einfachsten zu erklärende und am einfachsten zu verwaltende Policy. Es bedeutet aber auch, dass ihr in mehreren Ländern deutlich über dem lokalen Markt zahlt und trotzdem in Zürich oder London unter Markt bleibt. Für ein kleines Team kann sich die Prämie lohnen — Recruiting geht schneller, niemand verhandelt über Geografie, und Retention in günstigeren Märkten wird zum Nicht-Thema. Mit wachsender Kopfzahl geht die Rechnung meist nicht mehr auf.

Die versteckten Kosten sind nicht das Geld. Es ist, dass eine Bezahlung deutlich über dem lokalen Markt diese Engineers sehr schwer zu verlieren und sehr schwer loszuwerden macht. Performance-Management wird weicher, weil niemand jemanden aus einem Job drängen will, den die Person lokal nie wieder erreichen wird.

Anker plus Standortfaktor. Ihr legt Bänder für einen Ankermarkt fest und wendet dann eine veröffentlichte Anpassung pro Land an. Das ist das gängigste und am ehesten zu rechtfertigende Modell, vorausgesetzt ihr seid ehrlich darüber, was der Faktor darstellt. Basiert ihn auf Arbeitskosten — was Engineers dieser Stufe dort tatsächlich verdienen — nicht auf Lebenshaltungskosten. Lebenshaltungskosten-Indizes basieren auf Miete und Lebensmitteln und bilden nicht den Preis eines Backend-Engineers mit Erfahrung in verteilten Systemen ab, der von allen anderen bestimmt wird, die in dieser Stadt einstellen, einschließlich US-Unternehmen, die remote einstellen.

Marktgerechter Satz pro Land. Jeder Markt bekommt sein eigenes Band aus eigenen Daten. Am genauesten, am aufwendigsten, und am schwersten konsistent zu halten, wenn ihr eine:n einzelne:n Engineer in einem Land habt, für das ihr überhaupt keinen Benchmark habt.

Welches ihr auch wählt, veröffentlicht den Mechanismus intern, auch wenn ihr keine individuellen Bänder veröffentlicht. Engineers akzeptieren einen Standortfaktor weit eher als eine unerklärte Lücke, und sie werden die Lücke sowieso aus einem durchgesickerten Angebot oder einem Gespräch auf einem Offsite rekonstruieren.

Woher die Zahlen kommen

Öffentliche Gehaltsaggregatoren sind ein Ausgangspunkt und nicht mehr. Sie sind selbst gemeldet, verzerrt zugunsten derer, die sich die Mühe machen, ein Formular auszufüllen, mischen meist Tagessätze von Freelancern mit Angestelltengehältern und hinken dem Markt in schnelllebigen Segmenten hinterher.

Bessere Quellen, in grober Reihenfolge der Verlässlichkeit:

• Eure eigenen Angebotsdaten. Jedes Angebot, das ihr in den letzten zwölf Monaten gemacht habt, ob angenommen oder abgelehnt, mit Stufe, Markt und Ausgang. Abgelehnte Angebote sind die wertvollsten Daten, die ihr besitzt. Wenn mehrere Senior-Kandidat:innen in München am oberen Ende eures Bandes abgelehnt haben, ist euer Band falsch, nicht die Kandidat:innen.
• Gegenangebote und konkurrierende Angebote von Kandidat:innen in späten Prozessphasen. Behandelt sie mit Skepsis, aber erfasst sie. Das Muster über ein Dutzend Kandidat:innen hinweg ist aussagekräftig, auch wenn eine einzelne Zahl übertrieben ist.
• Recruiter:innen, die täglich in diesem Markt arbeiten. Eine Spezialistin, die technische und spezialisierte Personalbeschaffung in einem bestimmten Land betreibt, sieht jede Woche echte Abschlüsse — eine deutlich engere Stichprobe als jeder öffentliche Datensatz, und aktuell.
• Formale Befragungsdaten eines Vergütungsanbieters, wenn eure Kopfzahl die Kosten rechtfertigt. Genau, teuer, und in kleineren Märkten typischerweise dünn.

Baut euer Band aus mindestens zwei Quellen auf und schreibt auf, welche ihr verwendet habt. In einem Jahr, wenn jemand fragt, warum sich das Senior-Band in Lissabon bewegt hat, wollt ihr als Antwort eine Quelle und ein Datum geben können.

Währung, Inflation und die Länder, die eure Tabelle sprengen

Ein in Euro denominiertes Band verhält sich in einem Eurozonen-Land ganz anders als in Polen, Rumänien, der Türkei oder Großbritannien. Zwei Dinge bewegen sich unabhängig voneinander: der Wechselkurs und die lokale Lohninflation. Sie bewegen sich nicht zusammen, und sie bewegen sich zu keinem vorhersehbaren Zeitpunkt zu eurem Vorteil.

Die praktische Entscheidung ist, ob die Mitarbeitenden dieses Risiko tragen oder ihr. Wenn ihr einen fixen Betrag in Lokalwährung zahlt und die Währung stark schwächelt, sinken eure Kosten, und der reale Lohn eures Engineers fällt — und sie werden anfangen, sich umzusehen. Wenn ihr einen an den Euro gekoppelten Betrag zahlt, steigen eure Kosten mit jeder Kursbewegung, und in einem Hochinflationsmarkt könnt ihr trotzdem hinter das lokale Lohnwachstum zurückfallen, weil lokale Gehälter dort schneller inflationieren können, als die Währung abwertet.

In Märkten mit anhaltend hoher Inflation — die Türkei ist das klarste europäische Beispiel — reichen jährliche Überprüfungen nicht aus. Lokale Arbeitgeber dort führen halbjährliche oder sogar häufigere Anpassungen durch, und ein ausländischer Arbeitgeber, der nur einmal jährlich überprüft, wird deutlich vor dem nächsten Zyklus im Rückstand sein. Legt euren Überprüfungsrhythmus pro Markt fest statt global, und teilt den Leuten mit, wie dieser Rhythmus aussieht. Die Verpflichtung zur Überprüfung ist mehr wert als die Höhe einer einzelnen Erhöhung.

Wenn ihr eine größere Offshore- oder Nearshore-Gruppe betreibt, ist das eines der stärksten Argumente für eine:n Partner:in, der/die den Aufbau dedizierter Teams und den laufenden Betrieb vor Ort übernimmt — der Anpassungszyklus, das Benchmarking und das Retention-Gespräch werden im Markt selbst gehandhabt, statt aus einer Konzernzentrale-Tabelle abgeleitet zu werden.

Wenn jemand das Land wechselt

Das wird passieren, und es ist die Frage, die eure Policy beantworten muss, bevor sie auftaucht.

Die drei vertretbaren Positionen sind: Die Bezahlung folgt sofort dem Standort, die Bezahlung wird eingefroren, bis das Band aufgeholt hat, oder die Bezahlung ändert sich überhaupt nicht. Wählt eine davon. Das schlechteste Ergebnis ist, es von Fall zu Fall zu handhaben, denn der erste Engineer, der von Berlin nach Valencia zieht und sein volles Gehalt behält, setzt einen Präzedenzfall für alle, und der zweite, dem gekürzt wird, wird es dem ganzen Team erzählen.

Ein praktischer Mittelweg: Wenn jemand in einen günstigeren Markt umzieht, haltet das Gehalt konstant und lasst künftige Band-Erhöhungen den Unterschied absorbieren. Niemand erleidet eine Gehaltskürzung, die Lücke schließt sich über einige Überprüfungszyklen, und die Policy ist einfach genug, um sie laut auszusprechen. Beachtet, dass ein Umzug auch Arbeitsrecht, Gehaltsabrechnung und Steuerpflichten verändert — ein Schritt, der wie eine HR-Entscheidung aussieht, erfordert oft ein völlig neues Beschäftigungsverhältnis.

Haltet die Struktur in einem System, nicht in einer Tabelle

Bänder driften, weil sie in einer Datei leben, die eine Person pflegt. Sobald ihr über ein paar Dutzend Leute in mehr als zwei Ländern hinausgewachsen seid, legt Stufen, Bänder, Gültigkeitsdaten und Ausnahmen in eurem HRIS ab, sodass jedes Angebot gegen die aktuelle Struktur generiert wird, und sodass ihr den einen Report fahren könnt, der zählt: Bezahlung gegen Band-Mittelwert, nach Stufe, nach Markt, nach Geschlecht, nach Betriebszugehörigkeit. Dieser Report bringt die Probleme ans Licht — den langjährigen Engineer, der unter das Band gefallen ist, das er mitdefiniert hat, den Markt, in dem jede Neueinstellung am oberen Ende landet, weil das Band veraltet ist — lange bevor jemand deswegen kündigt. Teams, die diesen Übergang noch nicht vollzogen haben, profitieren meist von einer kurzen Überprüfung ihrer HR-Tools und ihres Datenmodells, bevor sie einen weiteren Markt hinzufügen.

Die Fehlermuster, die man benennen sollte

• Verhandlungsgetriebene Bezahlung. Wenn die endgültige Zahl hauptsächlich davon abhängt, wie hartnäckig jemand verhandelt hat, habt ihr keine Bänder, und ihr habt eine strukturelle Lücke gebaut, die mit Selbstbewusstsein korreliert, nicht mit Beitrag.
• Bänder, die einmal festgelegt und nie wieder überprüft werden. Ein Band, das vor achtzehn Monaten richtig war, kostet euch jetzt entweder Kandidat:innen oder zahlt Neueinstellungen relativ zum bestehenden Team zu viel.
• Benchmarking gegen die falschen Wettbewerber. Eure Konkurrenz um eine:n Engineer in Krakau ist nicht das andere lokale Produktunternehmen. Es ist jeder Remote-first-Arbeitgeber, der in Polen einstellt, einschließlich solcher, die westeuropäische Sätze zahlen.
• Gesamtvergütung als Grundgehalt behandeln. Equity, Bonusstrukturen, Rentenbeiträge und arbeitgeberseitige Kosten unterscheiden sich enorm nach Land. Vergleicht Gleiches mit Gleichem, und sagt Kandidat:innen, was das Gesamtpaket in Begriffen wert ist, die sie lokal überprüfen können.
• Geheimhaltung als Strategie. Ihr müsst keine individuellen Gehälter veröffentlichen. Ihr müsst aber in der Lage sein, in zwei Sätzen zu erklären, warum zwei Personen unterschiedlich bezahlt werden. Wenn ihr das nicht könnt, ist das das Problem — nicht die Tatsache, dass jemand gefragt hat.