In der Softwarebranche werden die Begriffe „Programmierer“ und „Entwickler“ oft synonym verwendet. In der Praxis beschreiben sie aber zwei fundamental verschiedene Tätigkeitsprofile, und die Kluft zwischen beiden wächst gerade deutlich.
Zwei Profile, ein Berufsfeld
Ein Programmierer im engeren Sinne übersetzt Anforderungen in Code. Er beherrscht Programmiersprachen, kennt Frameworks und Bibliotheken und schreibt funktionierenden Code. Das ist eine anspruchsvolle Tätigkeit, die Präzision und technisches Verständnis erfordert.
Ein Entwickler tut das auch, aber seine Arbeit beginnt deutlich früher und endet deutlich später als beim Code-Schreiben. Ein Entwickler spricht mit Kunden und Fachabteilungen, erkennt Zielkonflikte zwischen verschiedenen Stakeholdern, versteht die geschäftlichen Rahmenbedingungen, kennt die technische Historie des Systems und übersetzt all das in eine belastbare Architektur.
Der Unterschied liegt nicht in der Qualität der Arbeit, sondern im Umfang der Verantwortung. Ein Programmierer verantwortet funktionierenden Code. Ein Entwickler verantwortet eine funktionierende Lösung.
Warum KI diesen Unterschied verstärkt
KI-Werkzeuge wie Claude Code, GitHub Copilot oder Cursor haben in den letzten zwei Jahren eine bemerkenswerte Reife erreicht. Sie können Code generieren, der syntaktisch korrekt ist, gängige Patterns implementiert und in vielen Standardsituationen auf Anhieb funktioniert.
Damit verschiebt sich die Wertschöpfung. Was bisher den Großteil des Arbeitsalltags eines Programmierers ausmachte, nämlich die eigentliche Code-Produktion, wird zunehmend von Werkzeugen übernommen. Das bedeutet nicht, dass Programmieren überflüssig wird. Aber es bedeutet, dass die Fähigkeit, Code zu schreiben, allein nicht mehr ausreicht, um den eigenen Wert in einem Projektteam zu begründen.
Was bleibt und was KI bisher nicht leisten kann, ist das Gesamtverständnis. Welches Problem soll eigentlich gelöst werden? Welche Rahmenbedingungen gibt es? Welche Kompromisse sind sinnvoll? Wo liegen die eigentlichen Risiken? Diese Fragen erfordern Kontext, Erfahrung und die Fähigkeit, mit verschiedenen Stakeholdern auf Augenhöhe zu kommunizieren. Jedes Unternehmen hat eigene Systeme, eigene Historie, eigene Komplexität. Das lässt sich nicht standardisieren.
Das Profil des wirkungsvollen Entwicklers
In der Branche gibt es den Mythos des „10x-Entwicklers“, also jemand, der zehnmal produktiver arbeitet als andere. Gemessen an der reinen Ausgabemenge mag das zutreffen. Gemessen am Kundennutzen ist die Rechnung eine andere.
Es gibt Entwickler, die technisch hervorragende Arbeit leisten, aber nie mit dem Fachbereich sprechen. Technische Experten, die jede Technologie beherrschen, aber nicht verstehen, welchen Nutzen der Kunde eigentlich braucht. Spezialisten, die bei der Frage nach der Gesamtarchitektur oder dem Geschäftskontext ins Stocken geraten.
Der Entwickler, der den größten Beitrag zum Projekterfolg leistet, ist selten der schnellste Coder. Es ist derjenige, der versteht, was der Kunde braucht, bevor dieser es selbst vollständig artikulieren kann. Der erkennt, wann eine elegante Lösung Overkill ist und wann ein vermeintlich einfacher Workaround langfristig zum Problem wird. Der proaktiv kommuniziert, wenn sich Risiken abzeichnen.
Der Unterschied zwischen „das Feature ist implementiert“ und „das Feature löst das Problem des Kunden“ ist oft genau dieser Entwickler.
Konkrete Veränderungen im Arbeitsalltag
In unserem Team hat sich die tägliche Arbeit durch KI-Werkzeuge merklich verändert. Statt jede Zeile manuell zu schreiben, beschreiben Entwickler zunehmend das Ziel und verfeinern den von der KI generierten ersten Entwurf.
Die Zeitersparnis bei der reinen Code-Produktion ist erheblich. Gleichzeitig steigt der Anspruch an die Begleitarbeit: Qualitätsprüfungen werden wichtiger, weil KI-generierte Ergebnisse subtile Fehler enthalten können, die auf den ersten Blick nicht sichtbar sind. Architekturentscheidungen müssen bewusster getroffen werden, weil die KI zwar Ergebnisse produziert, aber keine strategischen technischen Entscheidungen trifft. Und die Kommunikation mit dem Fachbereich bleibt vollständig beim Menschen.
Das verändert die Anforderungen an das Team. Wer bisher vor allem durch schnelle Code-Produktion aufgefallen ist, muss jetzt andere Stärken zeigen. Wer schon immer stark in Analyse, Kommunikation und Architektur war, wird durch KI-Werkzeuge noch wirkungsvoller.
Was das für Unternehmen bedeutet
Für Unternehmen, die Softwareentwicklung betreiben oder beauftragen, hat diese Verschiebung praktische Konsequenzen.
Beim Teamaufbau wird die Frage wichtiger, welche Rolle jemand im Gesamtsystem einnimmt. Ein Team aus exzellenten Programmierern ohne Kundenverständnis wird durch KI-Werkzeuge nicht besser. Es wird schneller, aber die Grundprobleme bleiben: falsches Feature gebaut, technische Entscheidungen ohne Geschäftskontext, keine Kommunikation nach außen.
Bei der Bewertung von Kandidaten lohnt es sich, weniger auf Framework-Listen zu schauen und mehr auf Problemlösungskompetenz. Ein Entwickler, der drei komplexe Projekte mit verschiedenen Technologien erfolgreich abgeschlossen hat, lernt ein neues Framework in Wochen. Ein Entwickler ohne Projekterfahrung, der fünf Frameworks beherrscht, braucht Monate, bis er in einem komplexen Umfeld produktiv wird.
Bei der Weiterbildung verschiebt sich der Fokus. Die technische Fortbildung bleibt wichtig, aber die Investition in Kommunikation, Anforderungsanalyse und Kundenverständnis wird zum differenzierenden Faktor. Das sind die Fähigkeiten, die KI nicht ersetzen kann.
Fazit
Die Unterscheidung zwischen Programmierer und Entwickler ist nicht neu. Aber KI macht sie erstmals wirtschaftlich spürbar. Reines Code-Schreiben verliert als alleinige Wertschöpfung an Bedeutung. Wer Probleme versteht, Lösungen gestaltet und mit Menschen kommunizieren kann, wird in den kommenden Jahren wertvoller, nicht weniger wert.
Meine Tochter hat eine Woche als Praktikantin in unserem IT-Unternehmen gearbeitet. Das Ergebnis vorweg: ITlerin wird sie nicht. Aber die Woche hat etwas über Motivation und Aufgabenverteilung sichtbar gemacht, das für jedes Team relevant ist.
Die Ausgangslage
Es war ein Notpraktikum. Schülerpraktikum steht an, keine Bewerbung geschrieben, Deadline rückt näher. Papa hat eine Firma, also los. Keine große Begeisterung, keine besonderen Erwartungen.
Die Aufgaben in der Woche waren bewusst gemischt: 24 Netzwerkkabel mit Beschriftungsfähnchen versehen. Ein AWS-Systemdiagramm in Confluence neu aufbauen, mit Kästchen, Pfeilen und Verbindungen, damit es endlich pflegbar dokumentiert ist. Dazu administrative Kleinigkeiten.
Alles wurde zuverlässig erledigt. Keine Diskussion, keine Nachfragen zu Sinn und Zweck. Im Büro wurde geliefert. Interessant, denn zu Hause wird über deutlich kleinere Aufgaben verhandelt. Aber das ist vermutlich ein allgemeines Eltern-Phänomen und kein Management-Insight.
Der Moment, der etwas gezeigt hat
Dann kam eine Aufgabe, die nichts mit IT zu tun hatte: Tech-Icons auf die Glastür meines Büros malen, damit niemand dagegen läuft, wenn sie geschlossen ist.
Der Unterschied war sofort sichtbar. Bei den IT-Aufgaben war die Haltung „wird erledigt“. Bei den Icons war sie „wird gestaltet“. Kreativität, Eigeninitiative, Stolz auf das Ergebnis. Die Energie im Raum war eine andere.
Der Unterschied zwischen „erledigt“ und „mit Begeisterung gemacht“ war nicht graduell. Er war fundamental. Und er hatte nichts mit Fähigkeit zu tun. Beide Aufgabentypen waren machbar. Der Unterschied lag in der Verbindung zwischen Person und Aufgabe.
Was das für die Führung in Softwareteams bedeutet
In Unternehmen wird viel über Performance, Skills und Produktivität gesprochen. Weniger oft wird gefragt: Womit identifizieren sich die Menschen eigentlich? Wo bringen sie freiwillig Energie rein, die über das Pflichtprogramm hinausgeht?
In der Softwareentwicklung ist dieses Muster täglich zu beobachten. Ein Entwickler blüht bei komplexen Architekturthemen auf, ein anderer wird lebendig, wenn er direkt mit dem Kunden spricht. Jemand ist in seinem Element bei Code-Reviews und Qualitätssicherung, ein anderer bei der Automatisierung von Prozessen.
Alle können ihre zugewiesenen Aufgaben erledigen. Aber die Qualität und das Engagement sind messbar anders, wenn die Aufgabe zur Person passt. Das ist keine neue Erkenntnis, aber sie wird in der täglichen Praxis selten konsequent umgesetzt.
Die Gründe dafür sind nachvollziehbar: Aufgaben werden nach Verfügbarkeit verteilt, nicht nach Neigung. Deadlines lassen wenig Spielraum für optimale Besetzung. In kleineren Teams muss jeder alles machen. Das sind reale Einschränkungen.
Trotzdem lohnt es sich, innerhalb dieser Einschränkungen so viel Passung wie möglich herzustellen. Das bedeutet nicht, dass jeder nur noch das macht, was ihm Spaß macht. Es bedeutet, dass die Aufgabenverteilung die individuellen Stärken und Interessen berücksichtigt, wo immer es möglich ist. Der Aufwand dafür ist gering. Die Wirkung auf Engagement und Ergebnisqualität ist erheblich.
Fazit
Eine Woche Schülerpraktikum hat etwas verdeutlicht, das in der täglichen Teamarbeit leicht untergeht: Der Unterschied zwischen Aufgabenerledigung und Aufgabenidentifikation ist sichtbar, messbar und gestaltbar. Die Aufgabe der Führung ist nicht, alle in die gleiche Form zu pressen. Sie ist, herauszufinden, wo die Passung zwischen Person und Aufgabe am größten ist, und diese Passung aktiv zu gestalten.
Meine Tochter wird keine ITlerin. Aber sie hat in einer Woche etwas sichtbar gemacht, das in vielen Teams übersehen wird.
In der IT-Branche werden Kandidaten nach einem Muster bewertet, das seiner Aufgabe nicht gerecht wird: Skill-Listen. Framework A, drei Jahre. Technologie B, nachgewiesen. Zertifikat C, vorhanden. Was sich als objektive Bewertung tarnt, ist in Wahrheit ein Filtermechanismus, der systematisch die falschen Signale priorisiert.
Das Muster
Die Situation tritt regelmäßig auf: Erfahrene Entwickler mit 10 oder mehr Jahren Projekterfahrung, die nachweislich Systeme gerettet, Teams verbessert und Kunden überzeugt haben, werden aufgrund einer Skill-Liste abgelehnt. Framework XY nur zwei statt drei Jahre Erfahrung. Branche X nicht „offiziell“ gemacht. Tool Y nicht im Lebenslauf aufgeführt.
Als würde Erfahrung nur zählen, wenn sie exakt in der richtigen Zeile steht.
Und dann die Gegenerfahrung: Sobald diese Entwickler im Projekt arbeiten, ist das Feedback durchweg positiv. „Tolle Arbeit.“ „Die beiden bitte bis zum Schluss behalten.“ Die Diskrepanz zwischen Filterergebnis und tatsächlicher Leistung ist frappierend.
Warum der Filter versagt
Das Problem hat eine nachvollziehbare Ursache: Skill-Listen sind einfach zu bewerten. Ein Häkchen setzen kann jeder. Einen Menschen einzuschätzen erfordert Urteilsvermögen, Erfahrung und Zeit.
In größeren Unternehmen entscheidet oft nicht die Fachabteilung über die Besetzung, sondern ein Einkaufsprozess. Profile werden gegen Anforderungslisten geprüft, teilweise automatisiert, teilweise durch Personen, die den technischen Kontext nicht beurteilen können. In diesem System fällt ein Java-Entwickler mit 15 Jahren Erfahrung durchs Raster, weil er ein bestimmtes Framework nicht im Lebenslauf stehen hat, obwohl er es innerhalb von zwei Wochen produktiv einsetzen würde.
Das ist kein Einzelfall, sondern ein strukturelles Problem. Und es wird durch KI im Recruiting nicht besser. Automatisierte Vorfilterung auf Basis von Keywords verschärft den Effekt: Wer die richtigen Buzzwords nicht im CV hat, kommt nicht durch die erste Filterstufe. Unabhängig von der tatsächlichen Qualifikation.
Was dabei verloren geht
Ein Senior-Entwickler lernt eine neue Technologie nicht in Monaten, sondern in Wochen. Das liegt nicht an besonderer Begabung, sondern an akkumulierter Erfahrung: Wer drei verschiedene Frontend-Frameworks gelernt hat, erkennt die gemeinsamen Patterns und braucht für das vierte einen Bruchteil der Einarbeitungszeit. Wer in unterschiedlichen Branchen gearbeitet hat, versteht neue Domänen schneller, weil er Parallelen erkennt.
Diese Art von Erfahrung lässt sich in keiner Skill-Matrix abbilden. Genauso wenig wie Kommunikationsfähigkeit, Eigenverantwortung oder die Fähigkeit, ein Problem zu durchdringen, bevor eine Lösung vorgeschlagen wird. Es sind aber genau diese Eigenschaften, die in komplexen Softwareprojekten den Unterschied machen.
Die Kosten dieses Filterproblems sind real, wenn auch indirekt. Stellen bleiben länger unbesetzt. Projekte verzögern sich. Am Ende wird jemand besetzt, der alle Häkchen hat, aber weniger Projekterfahrung und weniger Wirkung mitbringt. Sechs Monate später fragt sich das Team, warum das Projekt nicht vorankommt.
Alternative Bewertungsansätze
Die Alternative zum Skill-Listen-Ansatz besteht nicht darin, keine Anforderungen zu formulieren. Sie besteht darin, die richtigen Anforderungen zu formulieren.
Wirkung statt Werkzeuge bewerten: Nicht fragen „Kennt er React?“, sondern „Hat er komplexe Frontends gebaut, die in Produktion laufen?“ Ein Entwickler, der nachweislich komplexe Systeme erfolgreich umgesetzt hat, wird die spezifische Technologie lernen. Umgekehrt garantiert eine Technologie im Lebenslauf noch keine erfolgreiche Projektarbeit.
Muster statt Keywords suchen: Erfahrene Entwickler bringen Muster mit, die sich über Technologien hinweg anwenden lassen: Architekturmuster, Kommunikationsmuster, Problemlösungsmuster. Diese Muster stehen in keinem Lebenslauf, aber sie sind der Grund, warum erfahrene Entwickler in neuen Kontexten schnell produktiv werden.
Fachgespräch statt Checkliste: 30 Minuten Fachgespräch liefern mehr Informationen als jede Skill-Matrix. Wie denkt jemand? Wie geht er an ein Problem heran? Welche Fragen stellt er? Wie kommuniziert er über technische Sachverhalte? Diese Dimensionen lassen sich nicht automatisieren, und genau deshalb sind sie so aussagekräftig.
Referenzen aus realen Projekten: Was sagen ehemalige Projektleiter, Teamkollegen oder Kunden? Wie wurde die Person in konkreten Projektsituationen erlebt? Diese Informationen sind schwerer zu beschaffen als eine Skill-Liste, aber sie bilden die tatsächliche Leistungsfähigkeit deutlich besser ab.
Die Perspektive beider Seiten
Aus Sicht der Unternehmen ist der Skill-Listen-Ansatz nachvollziehbar: Er ist effizient, vergleichbar und skaliert. Bei 200 Bewerbungen auf eine Stelle ist ein automatisierter Filter verständlich. Das Problem ist nicht der Filter an sich, sondern die Kriterien, nach denen gefiltert wird.
Aus Sicht der Kandidaten ist die Frustration ebenso nachvollziehbar: Jahrelange Erfahrung wird nicht anerkannt, weil ein bestimmtes Keyword fehlt. Die Reaktion vieler erfahrener Entwickler ist, ihre Lebensläufe mit Keywords zu optimieren statt mit Substanz. Das verstärkt das Problem, weil die Skill-Listen noch weniger mit der Realität korrelieren.
Die Lösung liegt nicht in einem der beiden Extreme. Sie liegt in Bewertungsmethoden, die sowohl skalierbar als auch aussagekräftig sind. Das erfordert mehr Aufwand als eine automatisierte Keyword-Suche. Aber es liefert auch bessere Ergebnisse.
Fazit
Skill-Listen sind bequem, aber sie filtern nach den falschen Kriterien. Die tatsächliche Wirksamkeit eines Entwicklers zeigt sich in der Fähigkeit, Probleme zu verstehen und zu lösen, nicht in der Anzahl der Keywords im Lebenslauf. Unternehmen, die bereit sind, über die Skill-Liste hinauszuschauen, finden die besseren Kandidaten. Es erfordert mehr Aufwand bei der Bewertung. Aber es spart den deutlich höheren Aufwand, der entsteht, wenn die falsche Person im Projekt sitzt.
Fünf Jahre ist es her, dass Remote Work bei uns vom Ausnahmefall zum Standard wurde. Was mit Corona als Notlösung begann, hat sich zu einem festen Arbeitsmodell entwickelt, das im Arbeitsvertrag verankert ist. Die Erfahrungen dieser fünf Jahre sind differenzierter als die Diskussion um „Büro versus Homeoffice“ vermuten lässt.
Die Ausgangssituation
Der Wechsel war nicht geplant. Von einem Tag auf den anderen war das gesamte Team im Homeoffice. Ohne Konzept, ohne Vorbereitung. Das Setup der technischen Infrastruktur dauerte einen Tag. Was länger gedauert hat, war die Anpassung der Zusammenarbeit.
Die erste überraschende Erkenntnis: Die Produktivität ist nicht eingebrochen. Nicht in der ersten Woche, nicht nach dem ersten Monat, nicht nach dem ersten Jahr. Die Befürchtung, dass ohne physische Anwesenheit weniger gearbeitet wird, hat sich in fünf Jahren nicht bestätigt.
Die zweite Erkenntnis war weniger offensichtlich: Die Qualität der Zusammenarbeit hat sich verändert, nicht verschlechtert, aber verändert. Spontane Gespräche am Kaffeeautomaten fielen weg. Dafür wurden geplante Abstimmungen fokussierter, weil alle Beteiligten bewusst Zeit dafür reserviert hatten. Der informelle Austausch musste neu organisiert werden, statt zufällig zu passieren.
Was sich nach fünf Jahren zeigt
Produktivität: Konstant auf dem Niveau vor der Umstellung. Die Output-Qualität hat sich nicht verändert. Was sich verändert hat, ist die Verteilung der Arbeitszeit: Viele Teammitglieder nutzen die gewonnene Pendelzeit für fokussierte Arbeit in den Morgenstunden. Die produktivsten Stunden des Tages werden nicht mehr im Stau verbracht.
Zufriedenheit: Die Möglichkeit, den Arbeitsort selbst zu wählen, ist für viele im Team der wichtigste Faktor geworden, wichtiger als Gehalt, wichtiger als andere Benefits. Das hat Auswirkungen auf die Personalgewinnung: In Bewerbungsgesprächen wird Remote Work als erstes erfragt, noch vor Aufgabeninhalten und Vergütung.
Zusammenarbeit: Wenn wir ins Büro kommen, dann bewusst. Für Teamtage, für Workshops, für den gemeinsamen Austausch. Diese Tage sind qualitativ besser geworden, gerade weil sie freiwillig sind. Niemand sitzt pflichtmäßig im Büro und arbeitet an seinem Laptop, was er genauso gut von zu Hause tun könnte. Wer kommt, kommt mit einer Absicht.
Onboarding: Der Bereich, in dem Remote Work den größten Anpassungsbedarf erzeugt hat. Neue Teammitglieder brauchen bei Remote-Onboarding bewusstere Begleitung, weil der informelle Wissenstransfer („einfach mal über die Schulter schauen“) wegfällt. Das erfordert mehr Struktur: definierte Ansprechpartner, regelmäßige Check-ins, dokumentierte Prozesse.
4 Tage Homeoffice sind bei uns inzwischen im Arbeitsvertrag verankert. Nicht als Benefit, sondern als Arbeitsrealität, die sich in fünf Jahren bewährt hat.
Die Gegenbewegung
Parallel zu unseren Erfahrungen läuft in vielen Unternehmen eine Gegenbewegung: zurück ins Büro. Große US-Konzerne verordnen vier oder fünf Tage Büropflicht. Die Vorgaben gelten oft global, auch an Standorten, an denen es kein erkennbares Problem mit Remote Work gibt.
Die Begründungen sind aufschlussreich durch das, was sie nicht enthalten: Selten wird argumentiert, dass die Produktivität gesunken sei oder die Ergebnisse schlechter geworden seien. Stattdessen wird mit „Unternehmenskultur“, „spontaner Zusammenarbeit“ oder schlicht mit der Feststellung argumentiert, dass Mitarbeitende „nicht im Büro waren“.
Drei Aspekte dieser Entwicklung verdienen eine genauere Betrachtung:
Globale Lösungen für lokale Probleme: Wenn an einem Standort das Büro leer steht und an einem anderen alles funktioniert, ist eine pauschale Regelung für alle Standorte keine differenzierte Lösung. Sie behandelt unterschiedliche Situationen gleich, was per Definition mindestens eine Seite falsch behandelt.
Anwesenheit als Proxy für Produktivität: Wenn die eigentliche Sorge ist, dass Mitarbeitende nicht produktiv genug sind, ist Büropflicht keine Lösung. Sie erzeugt Anwesenheit, nicht Produktivität. Das sind zwei verschiedene Dinge. Ein unproduktiver Mitarbeiter wird durch den Umzug ins Büro nicht produktiv. Ein produktiver Mitarbeiter wird durch den Pendelweg nicht produktiver.
Pauschale statt differenzierte Ansätze: Manche Menschen arbeiten im Homeoffice besser, andere brauchen die Struktur des Büros. Manche Aufgaben erfordern fokussiertes Einzelarbeiten, andere profitieren von räumlicher Nähe. Ein Arbeitsmodell, das diese Unterschiede nicht berücksichtigt, sondern für alle das Gleiche verordnet, verschenkt Potenzial.
Was sich als Voraussetzung herausgestellt hat
Remote Work funktioniert nicht automatisch. In fünf Jahren haben sich drei Voraussetzungen als entscheidend erwiesen:
Ergebnisorientierung: Die Frage ist nicht „Wo arbeitest du?“, sondern „Was lieferst du?“. Das erfordert klare Erwartungen, definierte Ergebnisse und regelmäßige Abstimmung. Wenn die Ergebnisse stimmen, ist der Arbeitsort irrelevant. Wenn sie nicht stimmen, liegt das Problem selten am Arbeitsort.
Vertrauen: Remote Work funktioniert nur mit einem Team, dem man vertraut. Aber die Gegenfrage lautet: Wenn man seinem Team nicht vertraut, von zu Hause produktiv zu arbeiten, stimmt dann wirklich die Bürolösung, oder stimmt etwas mit dem Team nicht?
Bewusste Gestaltung: Der informelle Austausch, der im Büro nebenbei passiert, muss im Remote-Setting bewusst geschaffen werden. Das bedeutet nicht, Meetings zu verdoppeln. Es bedeutet, Gelegenheiten für ungezwungenen Austausch zu schaffen: regelmäßige Team-Calls ohne Agenda, gemeinsame virtuelle Mittagspausen, Bürotage mit sozialem Fokus.
Fazit
Remote Work ist kein Experiment mehr. Es ist ein Arbeitsmodell, das unter den richtigen Voraussetzungen, klare Erwartungen, Vertrauen, bewusste Gestaltung, funktioniert. Die pauschale Rückkehr ins Büro ist keine differenzierte Antwort auf die Frage, wie Zusammenarbeit am besten funktioniert. Sie ist die einfachste Antwort. Das ist nicht dasselbe.
Sie sehen gerade einen Platzhalterinhalt von Facebook. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von Instagram. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von X. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
