Skip to content

Gebote des Bewerbungsgesprächs

26. Mai 2015

Da sich allgemein gerne über dieses Thema „beklagt“ wird, dauerte es eine Weile, bis ich auf die Häufung der Klagen aufmerksam wurde. Jetzt hatte ich Gelegenheit, das hautnah mitzuerleben. Damit Euch die bekannten Fehler nicht passieren, hier eine Wiederholungen und Zusammenfassung des Kleinen Einmaleins des Bewerbungsgesprächs.

Für alle Leser, die es nicht kennen, hier der Hintergrund, warum ich in dieses Thema nicht ständig involviert bin. Wie Externe arbeiten. Und: Wann Externe, wann Interne eingesetzt werden.

Der Post ist lang. Die Gebote sind herausgehoben.

Als Externer betrachte ich diese Sache skeptisch, war schon immer der Meinung, dass andere Lösungen vieles einfacher machen würden – aber da ich nicht involviert bin, halte ich mich gerne aus solchen Sachen heraus. Dennoch ist meine Meinung seit ca. 20 Jahren stabil: Den Mitarbeiter seine Position selbst finden lassen, halte ich für die beste aller Lösungen. Bewerbungsfirmen sind in meinen Augen die zweitbeste aller Lösungen. Wenn es unbedingt in dynamischen, interdisziplinären Projekten eine persönliche Auswahl sein muss, dann halte ich es für die beste Lösung, wenn Vermittler die Firmen, Projekte und Teams kennen ebenso einen guten Überblick über die Kandidaten haben. Erst, wenn all diese Wege nicht gegangen werden können, dann würde ich mich auf einen Ressourcenfressenden Prozess, wie den hier vorgestellten oder den aktuell praktizierten einlassen.

Zum Thema Zeugnisse, wird nur in diesem Absatz etwas gesagt werden und das ist: Dazu hat jeder seine Meinung. Dass es so viele Meinungen dazu gibt, dass das Thema so umstritten ist, zeigt nur, dass es keine wirklich praktikable Lösung zu sein scheint.

Über Bewerbungen wird versucht, das eigene Team (in der Regel langfristig) aufzustocken. Viele Firmen versuchen sich KnowHow einzukaufen – das ist aber Sache der Externen und der internen Schulungen. Das KnowHow spielt schon deshalb eine untergeordnete Rolle, weil in jeder Firma jedes Werkzeug anders eingesetzt wird. Das gilt vor allem dann, wenn es sich um komplexe Werkzeuge dreht. Viele dieser Werkzeuge sind programmier- oder erweiterbar, der Name steht dann noch drauf, aber drin ist etwas ganz anderes. Wer viel durch die Firmen kommt, der weiss, dass deren Kapital der Arbeitsprozess ist. Durch ihn finden sich die Nischen und neuen Produkte, durch ihn werden die Produkte stabil und einsatzfähig. Doch auch er ist der Wandlung unterworfen und benötigt neue Ideen.

Für eine Bewerbung ist deshalb wichtig, dass der Bewerber sich schnell in der neuen Umgebung einleben kann, diese aufnehmen – und diese nur eine gewisse Zeit lang – kritisch beäugen kann, dann ist er „betriebsblind“ und sein innovatives Kapital ist verbraucht. KnowHow ist nur insofern wichtig, dass bestimmte Grundlagen gegeben sind. Das liesse sich zwar testen, wird aber im bestehenden Prozess wieder und wieder getestet. Ein etwas standardisiertes aber Aussage kräftigeres Verfahren als das nicht standardisierte, mutwillige, von den eigenen Misserfolgen strotzende Testverfahren, wäre hier sehr hilfreich. Das könnte zentral organisiert werden und könnte auch in „Bewerbungsfirmen“ integriert werden, diese können Aufträge entgegennehmen und von internen Teams lösen lassen (da eine Firma dahinter steht, ist die Gefahr, dass Ideen geklaut werden kleiner und die Chance, dass alles mit rechten Dingen zu geht grösser), die als Ganzes übernommen werden können oder es können einzelne Mitarbeiter empfohlen werden. Der Vorteil an Bewerbungsfirmen ist, dass bislang ruhendes Potenzial sich durchaus an heiklen Themen versuchen kann, der Druck auf die Entwicklungsabteilungen der Industrie steigt, aber das muss nicht schlecht sein. In manchen Märkten ist es sogar nötig, dass der Staat eine zusätzliches „Motivationsmittel“ hat, um stagnierende Märkte wiederbeleben zu können.

Mitarbeiter sucht seine Position selbst

Letztlich ist es egal, wie viel man im Vorfeld theoretisiert und was alles bedacht wird: Ist das Team zusammengestellt, dann garantieren gruppendynamische Effekte, dass sich jeder seine (inoffizielle) Position sucht und findet.

Statt diese inoffiziellen Positionen zu bekämpfen (wie es usus ist) tut jede Firma gut daran, sie zu nutzen. Nur die Anonymität grosser Firmen und die Berichtsstrategie stehen dazwischen.

Bewerbungsfirmen

In einer Bewerbungsfirmen werden die Kandidaten in einer Arbeitssituation, auf Herz und Nieren getestet, evtl. Scharten repariert, Schwächen – wenn möglich – ausgeglichen und die Stärken unterstrichen. Entlässt eine Firma einen Mitarbeiter, dann beteiligt sie sich an diesem Prozess, zumindest finanziell (das motiviert die Firma, die interne Weiterbildung zu verbessern und firmeninterne Alternativen zur Entlassung zu suchen – die gibt es). Es gibt Ausnahmen.

Die zentrale Aufgabe der Bewerbungsfirma ist es, ihre Mitarbeiter sehr gut einzuschätzen und dem Interessenten – wenn er ähnlich gute Daten liefern kann – den idealen Kandidaten zu nennen.

Die zweite zentrale Aufgabe ist die Weiterbildung und – sollten Aufträge von aussen ausbleiben – die Forschung. Damit wird eine Bewerbungsfirma zu einem hochinteressanten Arbeitgeber. Die den Standard einer Region setzt. Aufgabe der BF ist es, den Standard aktuell zu halten, die angesiedelten Firmen zu beraten und zu unterstützen. Wenn sie selbst der attraktiveste Arbeitgeber der Region sind, zeigen sie, dass sie mit anwendbarem, effektivem und nützlichem Wissen handeln und nicht graue Theorie. Sie werden zu effektiven Partner der Arbeitgeber.

Darf sie in Konkurrenz zu den ansässigen Firmen treten? Die Frage ist heikel, jedoch bereits beantwortet: Ja. Sie macht das unter Ansage. Prinzipiell wird die Zusammenarbeit bevorzugt, aber sie dient dem Markt, nicht der Firmenpolitik. Sie sucht Neues. Unterstützt die Entwicklung, hilft beim Aufbau und begleitet diese Firmen. Sie stellt das Gleichgewicht zwischen Markt- und Firmeninteressen her, setzt den Fokus auf Innovation und Entwicklung statt auf Grösse und Dominanz. Sie tut das umsichtig, aber entschieden.

Die Bewerbung

Es ist der gesamte Prozess zu beachten, von dem dieses Bewerbungsgespräch ein Teil ist. Die anderen Schritte werden jedoch nur genannt, nicht ausgeführt.

Zeiten, Dauern, Anfangswissenstand, Endwissenstand und welche Wissensgebiete begleitend nützlich wären, Überlappungen mit anderen Arbeiten und ein paar mögliche Projektierungen gehören zu den Vorarbeiten um den benötigten Skill, Temperament und Ehrgeiz ein Bewerber für diese Stelle aufweisen sollte.

Der erste Schritt ist die Festlegung dessen, was man sucht. Dieser Schritt wird umso schwerer, umso wichtiger die eigenen (endemischen) Prozesse und Werkzeuge sind – denn dann kann nicht nach diesen gesucht werden, sondern nur nach Ähnlichem.

Ansonsten wird nach Erfahrungen und im Besonderen nach Programmiersprachen und Werkzeugen gefragt. Wichtig ist, mit wie vielen Sprachen er meint vertraut zu sein, welcher Art diese sind und ob er die Sprache kennt oder kann. Er soll sagen, welche Aufgaben für ihn Herausforderungen waren und welche er sucht.

Alternativ kann nachgefragt werden, was er gerne mal machen würde oder was er nicht machen will. In allen Fällen gehört dazu, sagen zu können, was an Wissen nötig war, was neu war, und was noch dazu kommen wird bzw. warum es bislang nicht gemacht wurde oder er das nicht machen will.

Diese Darstellungen dürfen gerne etwas älter sein, denn sie sind nur dafür da, die Ziele und Interessen des Bewerbers zu skizzieren. Aktualisiert werden sie nur, wenn sich daran etwas geändert hat (dabei ist unwichtig, ob zwischenzeitlich die Ziele erreicht wurden).

Es geht nur um eine Art Selbsteinschätzung, die weit leichter für den Bewerber zu erstellen ist und für die Interessierten zu verstehen / interpretieren sind, als die aktuellen Methoden.

Im Bewerbungsgespräch (Smaltalkphase) kann daran angeknüpft werden.

Macht man die Vorauswahl selbst, dann wird in einem groben Filter alles weggenommen, was nicht die benötigten Erfahrungen hat – das sind in der Regel wenige. Der eigentliche Sinn dieses Schritts ist auch nicht das Entfernen von Kandidaten, sondern sich einen Überblick zu verschaffen.

Im zweiten Durchgang werden die konkreten und relevanten Fragen geprüft (auch hier sind Fehler eher selten und treten sie häufiger auf, dann sollt an der Beschreibung der Anforderungen und Erwartungen gearbeitet werden).

Vor dem dritten Durchgang werden die Kandidaten informiert und ihnen das nötige Wissen über Firma, Abteilung, Produkt und bislang bekanntem Team zugeschickt. Nun werden einige Kandidaten selbst einen Rückzieher machen.

Dann hat mal die Qual der Wahl. Die Beschreibung der eigenen Ziele und Leistungen werden nun relevant. Ich ziehe es vor, vom Sekretariat (oder vom Vermittler) ein kurzes Telefonat zu vereinbaren.

Sind es zu viele, wird ein Sammeltermin vereinbart und die Leute werden in eine „absurde Arbeitssituation“ gebracht (definitiv nicht produktiv) und sie wechseln ständig die Positionen. Da nahezu jeder Typ auf jeden trifft, kann das nicht gut durch Beobachtung konkrete allein ausgewertet werden, es sollte mit dem Fischauge Aufnahmen gemacht werden. Wenn eine Firma allein nicht genug Stellen anbieten kann, dann sollte man sich mit ein paar Firmen zusammentun.

Nach diesem Sammeltermin sind die potenziellen neuen Mitarbeiter sehr gut bekannt. Zum Bewerbungsgespräch kommt nur, wer noch auf Kompatibilität mit dem Team zu testen ist.

Dieser Bewerbungsprozess legt darauf wert, die Eigenschaften, Lernbereitschaft und die Rolle, die er in einem Team einnimmt oder anstrebt oder für gewöhnlich einnimmt und die Lösungen und Arbeitsbereitschaft in einem Umfeld zu erruieren, in dem nur schwer betrogen werden kann, weil es lange genug dauert. Es funktioniert umso besser, je mehr Firmen sich zusammen tun, weil sich so bessere Standards und Bewertungsverfahren festlegen lassen – die allgemein aussagekräftig sind.

Muss es unbedingt ein herkömmlicher Bewerbungsprozess sein, dann sollte man diesen so gestalten, dass sich die Bewerber selbst aussortieren können. Weder Personalbüros noch fachliche Spezialisten, können den Wissenstand korrekt messen. Der Bewerber merkt es sofort. Die Suchende Firma kann sich die Suche dramatisch erleichtern, indem ein Arbeitsprozess aufgesetzt wird, der – nach aussen – nicht von Werkzeugen abhängig ist und der einfach und selbsterklärend ist bzw. binnen weniger Stunden „gelernt“ werden kann.

Die Gebote

Frage nie konkrete Daten ab.

Es gibt so viele Lösungen wie es Programmierer gibt – und ein paar mehr. Abfragen kann man nur das eigene Wissen. Meist fragt man aber nicht ab, was man weiss, sondern, was bisher Probleme bereitete.

Letztlich werden nur die eigenen Grenzen aufgezeigt und (indirekt) der Kandidat von Anfang an auf ein bestimmtes Level eingeschworen.

Viele Programmierer arbeiten im „Flow“, sonst kann er nicht lösen (nur Coden nach Vorgabe oder „was der Lehrer“ gesagt hat). Im Flow macht man Dinge, an die man sich hinterher nicht wirklich erinnern kann – viele Programmierer wissen nicht, was sie alles drauf haben – und bereits gemacht haben bzw. sie könnten es nicht garantieren – wenn man es mit einer ehrlichen Haut zu tun hat. Selbst (oder besser: gerade die) selbstverständlichen Arbeiten werden dann abschlägig beantwortet obwohl sie schlicht dazugehören und selbstverständlich beherrscht werden

Dass auf diese Weise getestet werden könne, ob der Kandidat sich ausdrücken kann, ist in meinem Augen falsch, denn verinnerlichte Handlungen (nichts anderes ist Programmieren) kann man kaum „ausdrücken“. Beispiel: Fragt man jemanden, der gerade Fahrrad fährt, gerät er in Schwierigkeiten, viele stürzen. Weniger drastisch aber doch spürbar verunsichert wird auf die Frage „Wie fährt man ein Fahrrad?“ reagiert. Die meisten ändern das Thema und erzählen die Gefühle, die man beim Fahrradfahren hat oder Erlebnisse beim Fahrradfahren.

Jeder Programmierer hat sein eigenes Vorgehen und kommt unabhängig vom Wissen des Befrager zu seiner Lösung. Da genau diese Unterschiede viele Möglichkeiten schaffen, werden sie gesucht. Unterschiede kann man nicht abfragen (zumindest können sie nicht bewertet werden – wozu etwas in der knappen Zeit eines Bewerbungsgesprächs machen, das keine Aussagekraft hat?).

Jeder Programmierer arbeitet an sich, das was war ist abgehackt oder so verinnerlicht, dass es quasi „unbewusst“ oder automatisiert abläuft. Auf dieses Wissen wird aufgebaut (relevant ist, was man daraus lernen kann). Verschiebt man den Fokus des Probanden ins Alte, verunsichert man ihn und verfremdet so, das Ergebnis. Scheinbar positive Antworten bekommt man von den Langsamen, die bei jedem Schritt nachdenken müssen.

Es ist fraglich, ob man belastbare Daten bekommt; es ist fraglich, ob das Ziel „Wissen abfragen“ erreicht werden kann; es ist fraglich, ob die Spreu vom Weizen getrennt werden kann. Im Gegenteil: wenn Arbeit und Bewerbung zu unterschiedlich sind, wird man nur Bewerbungsprofis einstellen. Und wenn einer richtig gut in Sachen Bewerbung ist, wie gut kann er dann beim Arbeiten sein – wenn sein Talent woanders liegt?

Man kann nur Gleichheit bzw. Übereinstimmungen, das selbe Level feststellen. Das Ergebnis vom wirklich „Schlechten“ und das vom „richtig Guten“ wird sich kaum unterscheiden – man sortiert immer auch die Besseren aus.

Was abgefragt wird spricht sich herum – man unterstützt Netzwerke und das geht auf Kosten der Lösungsmöglichkeiten.

Es gibt kaum ein Werkzeug, das nicht „firmenspezifisch“ verwendet wird (ansonsten ist es beliebig austauschbar, eine Vorgabe dieses Werkzeug ist dann überflüssig, ebenso jegliches Abfragen, das dieses Werkzeug betreffen). Wenn man nicht nur Ehemalige finden will (was sehr viel einfacher bewerkstelligt werden kann) – was kann man dann abfragen, das relevant ist?

Stelle nie die Firma vor

Im Bewerbungsprozess sollte die Firma und die Aufgabe bereits vorgestellt sein (wenn nicht, dann all auf eine passwortgeschütze Internetsite stellen und Link mit individuellem einmal Passwort verschicken) bevor es zu einem Bewerbungsgespräch kommt. Es zu wiederholen bringt nichts. Es lockert auch nicht die Atmosphäre. Dazu reicht ein kurzer Smalltalk.

Das Bewerbungsgespräch ist keine Werbeveranstaltung und auch kein Marketing Event. Wenn es zu einem Bewerbungsgespräch kommt, sollte nur noch zu klären sein, ob die Person als solche in das Team, die Abteilung und / oder Firma passt.

Alle wichtigen Eigenschaften lassen sich in einer Stunde mit normalen Gesprächstechniken erfassen – zuverlässiger als mit jedem Formular.

Wichtiger, als die bekannten Produkte ist die Lern- und Aufnahmefähigkeit, die geistige Flexibilität und die Leistungsbereitschaft.

Wenn ein Vermittler zwischen Firma und Bewerber steht, ist es dessen Sache, geeignete Kandidaten und Firmen zusammenzubringen (wenn er die richtigen Informationen hat). Dass es generell zusammenpassen kann, davon sollte ausgegangen werden können.

Wenn es bei der Vorauswahl Schwierigkeiten gibt, dann liegt das meist an Missverständnissen und daran, dass man das Falsche fragt. Bzw. indirekt und / oder unbewusst Filter verwendet, die zu unspezifisch sind oder schlicht Unwichtiges in Erfahrung bringen.

Die häufigsten Missverständnisse sind: Es gibt das, was gesucht wird, nicht (weit über 70%). Illusionäre Vorstellungen und Forderungen, werden nur von Leuten „bedient“ werden, die selbst gut Illusionen wecken können – dieser Markt ist an sich schon klein und seine Mitglieder in aller Regel beschäftigt. Wenn diese Beschreibung nicht mit dem Vermerk „es wird ausgebildet“ ausgestattet wird, kann die Anfrage getrost unter „nicht ernsthaft“ abgelegt werden und sollte aus den Statistiken fliegen.

Es werden firmeneigene Begriffe verwendet, die „draussen“ nicht bekannt sind oder missverstanden werden können. Es ist besser festzustellen, wie gut der Bewerber mit dem Konzept IDE, Build Prozess etc. im Allgemeinen zurecht kommt; und es ist besser, den Mitarbeiter sein gewohntes Werkzeug verwenden zu lassen (für Arbeiten, an denen zwei oder mehr Mitarbeiter zusammen und interaktiv am Rechner arbeiten, ist ein minimal Werkzeug besser, als komplexe) als ihm ein Werkzeug aufzuzwingen. In der Regel sind diese Werkzeuge „oversized“, das bedeutet, dass man einem Mitarbeiter ein Werkzeug, das er nicht braucht, aufzwingt – und die Zahl der akzeptablen Bewerber künstlich reduziert.

Wenn der firmeninterne Prozess sich nicht nach aussen griffig portieren lässt, greifen viele auf viele Worte zurück, die wenig aussagen. Aussagen wie: „Die Einarbeitung wird ca. 4 Wochen betragen und benötigt Wissen in der Sprache XY und der Integration (Build-, Arbeits- und Organisationprozess) reichen dann aus.Die Kenntnis einer Programmiersprache kann wie folgt „abgefragt“ werden: „routinierter Anwender“, „kann Konzepte für diese Sprache anpassen und umsetzen“, „detaillierte Kenntnisse der Spracheigenheiten“, „Informatiker: hat einen Compiler für diese Sprache erstellt und ihn (evtl.) theoretisch untermauert“. In 80% aller Fälle reicht Stufe eins aus. Alles andere ist – je spezifischer der Arbeitsprozess ist – zu erlernen. Bei den restlichen 20% können die Wissensstände nicht wirklich abgefragt werden. Es ist sinnlos, das zu probieren.

In einer kooperativen Umgebung (zu der ich beim Erstellen von Software dringend rate) sind die Übergänge von Anfänger bis zum Informatiker fliessend und es finden sich überall die nötigen Ansprechpartner und Spezialisten. Bei der Bewerbung ist lediglich relevant, ob der Bewerber Level Eins oder Zwei mitbringen sollte (schon Level zwei lässt sich nicht mehr aussagekräftig abfragen) und welchen Ehrgeiz er in dieser Sprache entwickelt (wenn dem Bewerber klar ist, dass die Zahl der Mitarbeiter mit jedem Level sinkt, dann erlaubt ihm das, seine persönliche und ehrliche Tendenz zu nennen).

Stelle stattdessen eine Aufgabe in den Mittelpunkt

Programmierer sind Techniker. Stellt man ihm eine technische Frage, zeigt sich, wie er Aufgaben angeht und wie er sich (wahrscheinlich) „normal“ verhält. Mehr, schneller und konkreter kann man nicht erfahren, was man wissen muss.

Die Aufgabe darf ruhig skurril, sogar absurd sein. Sie sollte auf keinen Fall „produktiv“ umsetzbar sein – gute Programmierer machen zu, weil sie keine Ideen verraten wollen. Ausserdem schafft das überraschte Lachen etwas, was im Bewerbungsgespräch selten gelingt: Innere Spannungen werden abgebaut, der Mitarbeiter ist entlastet und kann nun gute evtl. ebenso absurde Lösungen liefern.

Stelle immer vor, was kommen wird

Dieser Punkt im Bewerbungsgespräch hat Vertragscharakter. Es wird gesagt, wo er stehen wird, wie der zeitliche Ablauf sein wird; stelle die Abteilungshierarchie vor (falls es sie gibt), auch die Organisation und die Punkte, die sehr gut funktionieren, die, die nicht gut funktionieren, und wer gerade an welchem Punkt arbeitet.

Dieser Punkt wird gerne unterschätzt und er wird gerne in Frage gestellt. Warum soll man einem „kleinen“ Angestellten sagen, was geplant ist – und so vielleicht nie passieren wird?

Weil er dann informiert ist, weniger Fragen stellt und schneller effektiv wird. Das ist die kurze Antwort. Die richtige Antwort ist: es gibt bei der Programmierung keine kleinen Angestellten (und wenn, dann wird Ressourcenverschwendung betrieben, dann macht man die Sache teurer, als es nötig wäre – warum das so ist, kann gern an anderer Stelle besprochen werden).

Praktisch jeder ist ein Manager – zumindest von sich und seinen Ressourcen und in der Firma für die Aufgaben, die ihm überantwortet wurden. Sie sollten auch so behandelt werden. Die Vorstellung von den Heerscharen an Programmierern, die nötig sind, war schon immer etwas übertrieben, die Werkzeuge entwickeln sich jedoch dazu, dass die fachlichen Arbeiten vom Kunden selbst durchgeführt werden und Programmierer diese optimieren diese Arbeiten und die dazu notwendigen Werkzeuge. Diese werden immer mächtiger, Codierer werden immer seltener werden. Die Frischlinge werden reichen – und es ist ein guter Weg, das Eingemachte kennenzulernen.

Ehrlich sein ist das Gebot dieser 10 Minuten. Wenn nicht, ist der Bewerber schneller wieder weg, als man ihn gewonnen hat oder aber er wird jede Gelegenheit nutzen – um sich „anzupassen“. Nur wenige verzeihen solche Tricks und selbst, wenn sie es wollen, ist das Betriebsklima meist so, dass sie meinen sich der Masse anschliessen zu müssen. (Wenn dies festgestellt wird, besteht dringender Handlungsbedarf).

Externe reden nicht über Weiterbildung usw. sie machen das von sich aus. Internen soll Weiterbildung angeboten werden (und Gelegenheit, das erworbene Wissen anzuwenden). Auch eine Schnelleinführung in die verwendeten Werkzeuge und wie sie eingesetzt werden (sagen Sie auch warum. Das dient der Reflexion – ist das Verhalten noch angebracht? Ist es überflüssig (viele Arbeitsprozesse können effektiv „aufgeräumt“ werden)? Sollte nach einem Ersatz gesucht werden? Die Einarbeitung von Neuen ist auch immer eine gute Gelegenheit, die Praxis zu hinterfragen.

Zeigen Sie auf, wie der Arbeitsprozess ist, wann und wo er dynamisch ist und wie die Eskalationsstufen sind. Es ist wichtig für den zukünftigen Mitarbeiter zu wissen, wann er tätig werden soll – vor allem dann, wann die Befehlskette zu vernachlässigen ist.

Verwendet wird nicht der „richtige“ Arbeitsprozess, sondern ein verallgemeinerter (in der kurzen Zeit könnte der richtige nicht ausgeführt werden). Das Ziel ist, die Informationen zu geben, die den Bewerber in die Lage versetzten „sich nützlich“ zu machen.

Die Bewerber vom Vormittag bekommen Gelegenheit mit dem Team Mittag zu essen. Die vom Nachmittag dürfen in der Kaffeeküche ein Teammitglied eine 1/4 Stunde interviewen.

Wichtig sind: Gibt es Zeiten, sich um neue Techniken zu kümmern? Kann man auch eigene Projekte verfolgen?

Leite die einzelnen Phasen mit einer kleinen Rahmengeschichte ein. Es ist ein wichtiges Gespräch und quasi ein erstes Meeting. Auch dort kommen die Teilnehmer aus den unterschiedlichsten Situationen und auch dort ist eine kurze, einführende Geschichte hilfreich, um einen zügigen Einstieg zu ermöglichen.

Gut geeignet ist, was zu dem Projekt geführt hat. Und klären Sie die Basis dieses Gesprächs – auch wenn es selbstverständlich erscheint, Missverständnisse können immer geschehen und versuchen sie vorbereitet zu sein. Wenn ein Proband die Stellenbeschreibung anders interpretiert hat, als sie gemeint war, dann klären Sie die verfänglichen Begriffe und nutzen Sie dennoch die Zeit, denn einen guten Mann sollte man nicht ziehen lassen. Es ist Ihre Aufgabe, dem Bewerber zu verdeutlichen ob dennoch eine Chance besteht und wenn welche. Es ist wichtig, dass das sehr klar und deutlich gesagt wird, denn wenn der Proband bereits im „Zeitverschwendungsmodus“ ist, helfen nur klare Perspektiven. Beispiel: „Diese Stelle scheint nicht die richtige für Sie zu sein, danke für ihre Hilfe, dieser Fehler wird uns nicht mehr unterlaufen. Wir haben aber Interesse an Ihnen gewonnen und denken, dass wir es dennoch miteinander versuchen sollten. Evtl. finden wir sehr bald eine geeignetere Position – wir suchen ja nicht nur für diesen Posten, das können wir gleich klären …“ oder: „… beginnen sollten wir jedoch mit diesem Posten, das Team ist flexibel und es wird ihre Möglichkeiten gerne nutzen. In einem viertel Jahr treffen wir uns wieder und besprechen die Situation und Modalitäten.“

Nervosität, Fokus, was gehört wird, welche Dinge welches Gewicht für den Probanden haben – das alles und sehr viel mehr kann aus den Reaktionen des Probanden während der Geschichte und dem sie daraus entwickelnden Gespräch entnommen werden.

Wann immer ich Bewerber bewerten sollte, redete ich mit ihnen auf diese Art vor oder nach seinem Bewerbungsgespräch und konnte genauer sagen, wofür er geeignet sein wird, als die, die das grosse Gespräch geführt haben. Allerdings durfte ich meine Gespräche in der Regel nicht mehr vor dem eigentlichen Bewerbungsgespräch führen, da die Bewerber sehr viel entspannter in die Gespräche gingen und das die Bewertungsgrundlage verfälschte.

Warum Externe nicht ständig in Bewerbungsgespräche involviert sind. Obwohl sie so häufig wechseln – oder gerade deshalb.

Als Externer ist das Verfahren anders. Der Grund war simpel: Entweder meldete sich der nächste Auftrag von selbst (sicher 80% der Fälle) oder es lief über einen Vermittler.

Der Vermittler kennt jeden Kunden und jeden Programmierer persönlich, kennt die Projekte und weiss deshalb, wer wann wohin passt.

Wenn man ein Projekt vermittelt bekam, lief das in der Regel wie folgt ab: Anruf, kurzes Gespräch mit Frage (ab wann verfügbar) und Info (wann und was ansteht), eine Entscheidung, gefolgt von einem Mail (meist schon ein paar Stunden später) mit allen relevanten Informationen incl. bereits gebuchtem Hotel, erster Anreise etc. (ein Vermittler bestellte immer ein Taxi zum Flug oder Zug, dann wurde man von einem Mann mit einem Schild in der Hand abgeholt. Das erste Mal wurde ich tatsächlich rot im Gesicht, später reduzierte sich das auf: „Hallo, schön dass Sie mich abholen. Tun Sie mir bitte einen Gefallen und stecken Sie das Ding weg.“).

Die Vermittlung des neuen Projekts war oft eine Sache von weniger als 10 Minuten und konnte zwischendurch erledigt werden. Da man selbst nur Unverbindliches oder Ja bzw. Nein zu sagen hatte, konnten diese Gespräche auch in heiklen Situationen angenommen werden.

Es setzt allerdings voraus, dass sich beide Seiten auf den Vermittler verlassen konnten. Er war eine Vertrauensperson. Sie hatte detaillierte Kenntnisse der Firma, Produkte, Projekte und geplanten / besetzten Teammitglieder und der Bewerber. Die Vermittler waren meist ehemalige Programmierer – sie kamen von der technischen Seite, die sich in das Administrative eingearbeitet hatten – und sie nahmen, wenn gewünscht, viel von den anfallenden administrativen und organisatorischen Arbeiten abnahmen.

Die „Projektler“ konnten sich ganz auf den Vermittler verlassen und sich zu 100% auf die anstehende Arbeit konzentrieren. Einige Vermittler stapelten bewusst tief und nannten sich „das Sekretariat“.

Die Zahl der Kontakte der Vermittler zu Firmen und Projektler war übersichtlich (um im Blog zu bleiben, sie war kleiner 150). Es gab mehrere Vermittler und sie kannten sich alle untereinander, sie konnten die Aussagen und Bewertungen ihrer Kollegen einschätzen, dennoch wollten sie einen unbekannten Projektler kennenlernen, das geschah meist in der Mittagspause und das Gespräch wurde beim aktuellen Kunden geführt.

Freilich war der Vermittler „zufällig“ zu früh dran und hatte so Gelegenheit, den Kandidaten während der Arbeit zu beobachten (es ist erstaunlich, aber die Jungs sind selbst in ansonsten hermetisch abgesicherte Bereiche gekommen). Das Vorgehen war bekannt und wurde von allen unterstützt. Das sich anschliessende Gespräch war mehr ein Plausch als ein Kreuzverhör, keiner wollte es sich mit dem anderen verscherzen, aber, mit den richtigen Fragen zum richtigen Zeitpunkt (wenn Ihr das auffrischen wollt, dann nur zu, ich kann auch einen kleinen Kurs machen, weil es ja „nur“ Auffrischung ist), ist es sehr aussagekräftig und intensive Arbeit auch, wenn Beobachter einen ganz anderen Eindruck haben könnten.

Demgegenüber die aktuelle Praxis: Formulare. Verwaltung. Rechtliche Absicherung. Der Vermittler und seine schwere Tätigkeit steht im Mittelpunkt. Zeit für Service – Fehlanzeige.

Projektvermittlung ist keine Jobvermittlung. Projektler sind extrem pragmatische Menschen, die einen Auftrag annehmen, weil pragmatische Menschen an dieser Stelle gefragt sind. Es gibt verschiedene Gründe, um etwas von einem Projektler oder einem Team umsetzen zu lassen.

Der triviale Grund: Es ist kompakt genug und kann delegiert werden.

Dass man es nicht in der eigenen Firma delegiert, kann verschiedene Gründe haben: Es ist zu wenig, zu schnell oder zu viel oder zu lang, um es sinnvoll mit den eigenen Verfahren und der internen Organisation umzusetzen. Oder es wird nach Alternativen zu den eigenen Verfahren gesucht, dann ist es besser, das an Leute zu vergeben, die von den internen Prozesse keine Ahnung haben.

Ein Punkt, der gerne „Ärger“ macht, ist, wenn neue Produkte an Externe vergeben werden. Interne meinen oft, dass das ein Sahnehäubchen wäre, das sie gerne haben wollen. Es tut mir leid hier einigen die Illusionen rauben zu müssen, aber ein Produkt von Null neu aufsetzen ist alles andere als ein Sahnehäubchen und es wird auch nicht alles besser deshalb oder durch das neue Produkt.

Wie läuft das ab, ein Produkt „aufsetzen“? Es beginnt mit dem Gespräch mit dem Auftraggeber, dem, der das Produkt in Auftrag gibt, nicht dem, der es umsetzt. Der Auftraggeber hat in der Regel eine mehr oder minder vage Vorstellung, von dem was er will. Oft sind Vorschläge zu unterbreiten und der Entscheidungsprozess zu begleiten. Das endet (über etliche Zwischenschritte) in der Spezifikation des Produkts. Kann man agil arbeiten, dann kann in dieser Phase bereits angefangen werden und die stabilen Rahmenprogramme und nötigen Hilfswerkzeuge zu erstellen („damals“ konnte das auch eine Versionskontrolle oder ein eigenes make sein). Bei embedded systems kommt meist noch eine Bibliothek für die Ausgabe (GUI), bzw. die Anpassung vorhandener Bibliotheken an die wahrscheinlich eingesetzt Hardware dazu.

In dieser Phase kommt es nicht selten vor, dass ein Programmierer unglaubliche Mengen Kode in kurzer Zeit erstellt. Wie geht das? Projektler haben einen enormen Fundus, Erfahrung und Routine im Erstellen solcher Basiskomponenten. Es bleibt aber interessant, diese Arbeiten wieder und wieder durchzuführen, weil sich (Programmier-) Sprachen, eingesetzte Werkzeuge, der Kontext im Allgemeinen ändert und damit Varianten des bekannten Verfahrens nötig sind – von denen oft mehrere bereitgestellt werden, damit es etwas zum Testen gibt.

Getestet wird dieser Kode nur marginal, weil der Programmierer genau weiss, wo die kritischen Punkte liegen und was zu testen ist. An dieser Stelle bietet es sich den unterschied zwischen Internem und Externen aufzuzeigen. Wird in dieses Team ein Interner aufgenommen, dann begnügen sich die meisten – nach einem verzweifelten Kampf – damit, mit Rat zur Verfügung zu stehen, der auch gerne angenommen wird. Ich habe Interne gesehen, die mit Tränen in den Augen dastanden und deren Weltbild zerbrach, weil Code „im Dutzend billiger“ produziert wurde und wenn er den Output mit seinem – und es sind immer die Besseren, die für diese Arbeit bereitgestellt werden – vergleicht, wenn nur die Zahlen sprechen, dann würde auch ich verzweifeln. Aber die Zahlen sind hier nicht wichtig.

Das Vergleichen von Äpfeln mit Birnen ist keine einfache Disziplin. Deshalb scheitert man hier schnell. Wie lange brauchen Sie, um ein auswendig gelerntes Gedicht (oder Text) niederzuschreiben? Und wie lange brauchen Sie, um eines (selbst) zu schreiben? Was die Projektler tun, liegt zwischen beiden Aufgaben. Sie erstellen Varianten bekannter und routinierter Lösungen. In dieser Phase arbeite ich lieber mit wenigen Programmierer (gerne auch weit ab vom Schuss) zusammen, als mit vielen – es ist effektiver, das Ergebnis stabiler und schneller. Und, der aktuelle technische Stand ist berücksichtigt. Es werden Massen an Kode erstellt, aber das ist die Basis, beim Eingemachten sinkt die reine Zeilenzahl – Externe bleiben aber meist führend. Woran liegt das?

Ein Interner ist nicht nur Programmierer, ein Interner ist auch Mitglied einer Firma, die sich durch einen eigenen Arbeitsstil und Erfahrungen auf dem Markt etabliert hat. Keine dieser Eigenschaften ist beim Programmierer relevant. Werden die internen Zeremonien und Prozesse eingehalten, dann ist ein Programm ab einer bestimmten Grösse mit internen Mitteln nicht mehr zu stemmen.

Ein Interner überlegt bei jeder Arbeit, wie sich das auf die internen Prozesse auswirkt – und landet mit schöner Regelmässigkeit bei der bereits vorhandenen Lösung. Auch ändert ein Interner ein Punkt. Der Externe kennt diese Punkte nicht, er sieht nur die Aufgabe, die technische Umgebung, was er wie ändern muss und schreibt den Kode. Er muss nicht Rücksicht auf die Internas nehmen, er kennt sie nicht einmal und das ist sehr gut, denn er braucht sich nicht um seinen Job kümmern. Der ist: Erstelle nach dem Stand der Technik ein Produkt. Der Job des Internen beinhaltet die Reflextion, des Vorhandenen. Er übernimmt gerne Lösungen, die als sehr gut gelten, auch, wenn es technisch nicht mehr passt und alles nur kompliziert wird.

Die Vergabe von neuen Arbeitsprozessen und Produkte an Externe hat einen einfachen Grund: Externe sind nicht betriebsblind. Und wenn eine Firma hier „Vorgaben“ macht, statt das Potenzial zu nutzen, dann begeht sie einen grossen Fehler. Der Fehler ist messbar. Zwei einhalb Monate braucht der Externe um das Kernprodukt herzustellen, nach Art des Hauses, wären ein einhalb Jahre und insgesamt vier Mann nötig gewesen – und das ist nur ein Beispiel von vielen. Und, das ist das Ergebnis, wenn die Externe arbeiten dürfen.

Was ist besser: Interner oder Externer? Wieder werden Äpfel mit Birnen oder zwei Seiten derselben Medaille verglichen. Es braucht beide. Beide ergänzen sich. Und, es gibt für beide spezielle Typen, die das machen können. Der eine ist nicht besser als der andere. Aber es gibt Unterschiede. Der Projektler trägt viel mehr finanzielle und soziale Belastungen als der Interne. Extern bedeutet nun mal: weit weg von zuhause, Familie, Freunde und Bekannte. Er verbringt viel Zeit damit, sich mit den Änderungen in der Branche auseinanderzusetzen und braucht viel Zeit zwischen den Projekten, um seinem Sozialleben neue Impulse zu geben. Das alles ist unbezahlt. Viele suchen sich deshalb Kleinstkunden im Umfeld der sozialen Heimat, schreiben Bücher oder verlegen sich auf Hobbies. Nicht wenige steigen nach wenigen Jahren aus – viele von diesen krempeln ihr Leben vollständig um. Vom Heilpraktiker über Brauer und Gastwirt, Event-Veranstalter, Künstler, Aussteller bis zum Privatier, all das gibt es unter ihnen. Die meisten suchen sich etwas, wo sie intensiv mit Menschen zu tun haben – wenn sie das noch können.

Der Interne ist voll in einem sozialen Bett – das kann auch mal unangenehm sein und es hat Folgen. Eine Folge ist, dass er im aktuellen Produkt „festsitzt“. Von den aktuellen Techniken hat er meist nur gehört (ich kenne heute noch Menschen, die C programmieren und für die Objekte und UML ein Fremdwort ist), er würde es gerne mal probieren, aber der Alltag lässt das nicht zu. Seine Aufgabe ist es, das bestehende Programm so weit es geht anzupassen – eine Redesign bestimmter Passagen oder des ganzen Produkts ist sein Ziel. Er steckt so tief in der Materie drin, dass die internen Gegebenheiten sein Denken leiten, nicht die Technik. Seine Ziele sind auf das gerichtet, was ihn bislang gestört hat – ansonsten ist er zufrieden.

Versucht man nur mit Internen ein neues Produkt aufzusetzen, dann erlebt man sehr schnell Grabenkämpfe. Jeder will, dass das neue Produkt so gut wie nur irgend möglich sein wird und das vor allem in den Passagen, für die er in Zukunft verantwortlich zeichnet. Was da abgeht, hat mit Programme schreiben nichts mehr zu tun. Ein Historiker freut sich allerdings, denn nach dem Besuch eines solchen Meetings, weiss er sehr genau, was die letzten fünf oft mehrere Jahrzehnte in der Firma passiert ist. Sehr genau. Nur nicht konstruktiv – für ein Programm und Produkt.

Es gibt noch andere Arbeiten, die gern an Externe vergeben werden. Da ist der Springer. Er ist als einziger Externer einer, der die Internas kennen darf – alle anderen Externe, die Internas kennen, sind „verbrannt“, wurden betriebsblind und haben bei diesem Kunden in der nächsten Zeit nichts zu suchen oder werden zum Internen (was selten gut geht). Der Springer zeichnet sich durch folgende Eigenschaften aus: Er hat einen grossen Überblick und kann überall eingesetzt werden. Er ist selten bis nie in die Teams integriert, er kennt sie alle, auch die Teilnehmer, ist aber, da nur in Lastzeiten da und als belastbares Arbeitstier bekannt und beliebt, dann aber auch schnell wieder heraus komplementiert, weil er das Potenzial hat, das gesamte Gefüge durcheinander zu bringen. Die Kunst des Springers ist es, keinerlei Karriereambitionen in der Firma zu haben – die werden jedoch immer unterstellt. Viele Springer werden deshalb nach einer gewissen Zeit aus der Firma gebissen. Er braucht deshalb mehrere Kunden, bei denen er Springer ist und braucht weitere Argumente, die zeigen, dass er keine Ambitionen hat, hier Karriere zu machen. Das geht am Besten über seinen Preis – den er auch wert sein muss. Dann wird er geholt, wenn Not am Mann ist und niemand muss argumentieren, wenn er nicht mehr gebraucht wird, weil er dann schlicht zu teuer wird.

Der Powercoder. Er kommt in der Regel mit der eigenen Hardware an, braucht einen ruhigen Arbeitsplatz, will genau einen Ansprechpartner, gut vorbereitete Arbeitsmaterialien und ansonsten seine Ruhe. Aus den oben beschriebenen Gründen, produziert er Kode in gigantischem Umfang. Nicht mehr aber auch nicht weniger. Er ist seinen Preis wert (das weiss zumindest jeder, der so etwas einmal erlebt hat).

Der Spezialist. Er bringt (und lehrt!) Wissen und Praxis, das in der Firma fehlt. In seltenen Fällen, wird ihm auch die Pflege des von ihm Produzierten übertragen, doch ist es ihm meist lieber, wenn das Interne übernehmen, für die er gerne Ansprechpartner bleibt.

Der Trainer und Coach. Auch er bringt Wissen in die Firma, aber auch Vorgehen und Verhalten. Zwei Arten gibt es: Technisch und menschlich. Der technische Trainer bringt den Umgang mit Werkzeugen und Prozessen bei, der menschliche soziale Kompetenzen aber auch verhandeln und Konfliktbewältigung etc.

Der Berater. Er verschafft sich einen Überblick und gibt erstaunlich schnell aber präzise Auskunft darüber, was wo (oft auch warum) hakt. Er kann das, weil er ständig in den unterchiedlichsten Firmen unterwegs ist und vieles kennt, was für die Firma selbst gerade das erste Mal vorkommt oder noch nicht als problematisch angesehen wird oder als heilige Kuh, die nicht angefasst werden darf. Seine Aufgabe ist es genau diese Punkte – die Unaussprechbaren und die (noch) nicht bekannten – anzusprechen. Seine Entlohnung grenzt an Schmerzensgeld. Kommt ein technischer, organisatorischer Berater, der sein Geld wert ist, dann kochen die Gefühle hoch – niemand wird gerne so unerbittlich kritisiert bzw. hinterfragt und – hinterher wieder aufgebaut. Er kommt im Krisenfall oder regelmässig. Ziel ist es einem effektiven Betrieb die Betriebsblindheit zu nehmen und die Objektivität zurück zu geben. Er macht einen Betrieb zukunftssicher – soweit man das durch Bewusstsein, Reflexion und Flexibilität in Denken und Handeln erreichen kann.

Der Teambuilder. Er ist wie der Berater, allerdings für ein Projekt und meist von Anfang an im Projekt vor allem, wenn Wissen und / oder Erfahrung im Team fehlen. Er ist anfangs Mädchen für alles, gibt die Aufgaben dann sucsessive ab, arbeitet die Mitarbeiter ein und organisiert alles. Wenn ich in diese Rolle komme, über nehme ich meist noch die Architektur und Designvorgaben und erstelle Prototypen für die zentralen oder besonders schweren Passagen. Ziel dieses Einsatzes eines Externen ist es kritischen Produkten gute Startbedingungen zu liefern. Ein Produkt ist dann kritisch, wenn zu viele unerfahrene Mitarbeiter im Team sind (oder an kritischen Positionen) sind, wenn viel neuer Kode erstellt werden soll, wenn die bisherigen Lösungen als ungeeignet empfunden werden oder wenn ein Produkt neu aufgestellt wird.

Mit Bewerbungen bekommt der Externe es nur zu tun, wenn er an dieser Position („Mädchen für alles“) steht und selbst dann lassen es sich meist die Internen nicht nehmen, diese Gespräche zu führen – es ist ihr gutes Recht und ich bin ihnen deshalb nicht böse, bin froh, wenn die Jungs was selber machen. Externe geben gerne ab. Dazu ist es aber nötig, dass sie es zuerst erstellen.

Externe machen genau einen Job und nehmen – weil sie es nicht wissen können und dürfen – nicht Rücksicht auf die Interna, Vorgehen und heiligen Kühe. Wird das von einem Externen erwartet, dann ist er in einer Internen Position gelandet, bis auf den Springer sollte er sich aus dieser – in Deutschland auch gesetzlich – fragwürdigen „Anstellung“ verabschieden.

Ein Arbeitnehmervermittler ist kein Projektvermittler. Um das hier etwas genauer zu differenzieren: Ein Projekt ist auf Zeit, hat eine klare Aufgabe und Ziel und so wenig Vorgaben, wie möglich. Man kann Werkzeuge bedienen, aber mit welchen gearbeitet wird, das sollte offen bleiben.

Vorgaben, die z.B. zu verwendende Werkzeuge betreffen, sollte der Kunde im besten Egoismus lassen. Ob ein Projekt heute erfolgreich ist oder nicht, hängt massgeblich von den eingesetzten Werkzeugen ab. Macht er hier Vorschriften, dann gefährdet er mit jeder Vorgabe sein eigenes Projekt. Wurde früher der Fokus auf die Versionskontrolle und statistischen Auswertungen gelegt, so geht er heute zu Codegeneratoren und andere Hilfswerkzeuge bis zu speziellen Compilern und anderen Werkzeugen, die Arbeit am Code abnehmen bzw. die Kodierung vereinfachen oder abnehmen. Aus dem Standard: Code erstellen, compilieren, zusammenstellen und testen wird: In Werkzeugen arbeiten, die Ergebnisse zusammenfassen und das Endergebnis mit weiteren Werkzeugen daraus erzeugen lassen. Wesentlich schnellere Releasezyklen, Erweiterungen und Wartungen kommen aus den Werkzeugen, werden selten von Hand erstellt sondern nur noch abgerufen. In dieser dynamischen Situation eine bestimmte Versionskontrolle oder Werkzeuge oder Verfahren vorzuschreiben, in der sich die Arbeitsprozesse schon ändern, wenn sich die Zahl der Programmierer ändert, stellt eine machbare Aufgabe, aber praktisch jede kostet Features, Zeit und vergrössert den administratitiven Aufwand. Zur Zeit werden die neuen Standards gesucht, bestimmt sind sie noch nicht und ob es gelingt je wieder einen Arbeitsprozess aufzubauen, der von der IDE alleine bewältigt werden kann, ist fraglich.

Beim Thema Externer ist immer auch ein anderes Thema wichtig: Welche Werkzeuge kennt der Externe, was macht er und wie unterscheidet er sich von einem Frischling? Ein Frischling erlernt praktisch jedes Werkzeug neu. Das ist ein Kampf und dauert oft sehr lange. Deshalb verweigern viele, die ein neues Werkzeug verwenden sollen, die Arbeit. Externe hatten weniger Ärger und haben das andere Werkzeug kurz nachdem es auf den Markt kommt, probiert und seine Erfahrungen damit gemacht. Oder sie kennen ähnliche Werkzeuge und benötigen in einer kleinen Testserie nur die Deltas – das äussert sich dann in einem Spickzettel, der ein paar Tage lang neben der Tastatur liegt (wird aber nach dem Erstellen nur noch selten betrachtet).

Ich kenne kaum einen Externen, der die Bedienung seiner Werkzeuge paukt. Fragen sie einmal einen Externen, wie man in dem Werkzeug, das er gerade bedient, etwas macht, das er gerade nicht macht und beachten Sie seine Finger. Entweder werden sie unmittelbar von der Tastatur weggerissen, wahrscheinlich aber ist, dass bereits Fehleingaben gemacht wurden oder er beginnt zu Lachen (weil er das kennt und mit dem Lachen den internen Konflikt auflösen kann).

Die meisten Programmierer denken Schleife über X wenn X > 100 beenden ansonsten Body. Die Finger schreiben die Schleife und die Finger entscheiden meist auch, welche Schleife verwendet werden sollen. Gibt man einem Programmierer einen Code, der nicht von seinen eigenen Fingern erstellt wurde, dann kann es sein, dass er wie der Ochs vorm Berg steht. Gibt man einem Externen einen Code, der von einem anderen erstellt wurde und davon nur ein Snippes, dann wird sein Gehirn unmittelbar damit beginnen, den fehlenden Code und die wahrscheinliche Aufgabe zu ergänzen. Er will den Überblick, den Kontext, dann schaut er sich das erste Mal den Snippes genauer an.

Eben weil der Programmierer den Kode nicht „bewusst“ Buchstabe für Buchstabe schreibt, schaut er sich zunächst die Fehlermeldung an, wenn der Compiler zickt und weiss in vielen Fällen bereits aufgrund der Fehlermeldung was schief gelaufen ist.

Hingegen wird er sich in fremdem Code a) nicht wohlfühlen b) zuerst die Aufgabe wissen wollen und c) wie er es lösen würde. Der Programmierer geht die eigen Lösung durch, schaut sich den Code an, stellt Fragen, warum das eine oder andere so gelöst wurde und erst, wenn er das versteht, dann schaut er sich den Fehler an.

Ein Frischling geht anders vor (übrigens auch die Programmierer, die Grossrechner programmierten und die Zeit hatten, jeden Kode mehrere Tage am Schreibtisch zu testen, ehe der Code das erste Mal ausgeführt wurde – das war aus Kostengründen so. Die Laufzeit eines Grossrechners kostete so viel, dass sie der Schreibtisch aufwand des Programmierers rechnete, heute hat sich das ins Gegenteil verkehrt). Der Frischling geht im Kopf alle gelernten Lösungen durch, sucht Abweichungen und schaut nach, ob es ein Fehler sein könnte. Er braucht weder Kontext noch Aufgabe – eine beneidenswert einfache Welt. Dieser Ehrgeiz hilft im Projekt jedoch nicht.

Ein Externer kann vier bis fünf grössere Kunden im Jahr haben und hat in der Regel noch ein paar kleinere. Bei jedem findet er andere Werkzeuge vor (oder wird gebeten, diese einzusetzen) und ist dennoch binnen kurzer Zeit produktiv. Viele Externe kennen noch die Zeit, in der jede Firma ihre eigenen Werkzeuge entwickelt hat. Es gab Zeiten, in denen der Compiler variiert wurde, damit bestimmte Dinge möglich wurden. Viele machten eigene Präprozessoren, um bestimmte Dinge einfacher kodieren zu können. Versionskontrolle wurde mit einer Datenbank gemacht. Make- Prozesse erweitert und gegebenen Falls erweitert, damit zentral auf einem Server compiliert wird usw.

Ich kenne kaum einen Externen, der lange braucht um ein Werkzeug kennenzulernen. Der Trick ist, dass er sein Gedächtnis verwendet. Das hat eine Eigenschaft, die in diesem Zusammenhang überrascht, aber effektiv ist: Vergessen. Oder er verwendet seinen extended memory: seine Finger. Er weiss, was er will; er weiss, wie das in ungefähr gemacht wird, wenn er zu einem Kunden kommt, geht er die Funktionen, die er braucht – und das sind in aller Regel sehr viel weniger, als die Werkzeuge anbieten – übt sie kurz und das war es dann. Es ist kein Hexenwerk und man mact kein grosses TamTam darum, es gibt anderes, das wichtiger ist.

Freilich tut sich der Frischling da schwerer. Das erste Tool einer Art ist das schwerste, das zweite geht dann schon relativ schnell, wenn sich die Werkzeuge signifkant unterscheiden, braucht es etwas länger, dennoch hat man Glück gehabt, weil dann das dritte und vierte sehr viel schneller geht.

Als Interner wurde man mit dieser Situation selten konfrontiert. Das ändert sich nun. Ziel des Arbeitsprozesses ist es heute, die Zahl der einzusetzenden Werkzeuge so klein wie möglich zu halten und dennoch alle nötigen einzusetzen. Das geht, aber das wird hier nicht weiter ausgeführt.

Die signifikanten Unterschiede zwischen Intern und Extern sind, dass der Externe da macht, wofür man keine internen Kenntnisse braucht oder bei dem bewusst auf interne Kenntnisse verzichtet wird, um Betriebsblindheit auszublenden, weil diese auch ein Hindernis zu einem Hindernis werden können, weil Gewohnheiten und Routine einen schnell machen, aber auch blind für andere Lösungen und da andere Lösungen im Haus noch nicht erprobt sind, werden sie zum Risikofaktor, doch der wird nie nachgewiesen. Wer nur mit Internen arbeitet verfestigt nur die bisherigen Wege. Dann wird es sehr schwer Neues auszuprobieren. Das auf eine einzelne Person zu schieben funktioniert nicht. Gruppendynamik trifft es eher.

Zu erleben, wie mächtig Gewohnheiten sind, ist das tägliche Brot eines Beraters, der eine Neuerung eingeführt. Dabei ist es völlig unwichtig, ob es sich um eine grosse oder kleine Änderung handelt. Das erste Mal ist man überrascht, dass man es tatsächlich fertiggebracht hat eine Änderung wurde akzeptiert! Das ist dann auch das erste Mal, dass man lernt, dass die Arbeit noch lange nicht getan ist. Die frustrierenden Momente sind: nach intensivem Üben wird der Mensch als neu ausgebildet, vielleicht sogar als Bester seiner Klasse, entlastet, er geht an seinen Arbeitsplatz – und ist sofort wieder im alten Trott.

Es tut immer wieder physisch weh. Nicht nur mir, oft auch dem, der es gerade gelernt hat – z.B. wenn aktuell noch die alten Werkzeuge einzusetzen sind, oder, wenn er merkt, dass er es auf dem Arbeitsplatz, auf dem er gelernt hat, einwandfrei und routiniert funktioniert, die Routine an seinem angestammten Arbeitsplatz aber stärker ist. Das erlebt man regelmässig. Tatsächlich ist eine der effektivsten Formen, den Umstieg zu unterstützten, die Arbeitsplätze neu zu arrangieren. Der zweit beste Weg ist öfter vorbei zu schauen. Es schleichen sich die alten Gewohnheiten immer wieder ein. Schliesslich sind sie voll automatisiert und um die neuen Wege gehen zu können ist es nötig, sich selbst ständig zu beobachten, man wird langsam und der gefährlichste Zeitpunkt ist der, wenn man meint, dass jetzt die neuen Wege verinnerlicht sind. Fast jeder, der intern diese Entscheidung getroffen hat, ist am nächsten Tag voll in den alten Fahrwasser.

Das darf man keinem übelnehmen. Externe, die sich darüber wundern, sollten nicht vergessen, dass sie selten derart lang „geprägt“ wurden, und man darf einen kompletten Wechsel der Arbeitsprozesse auch nicht mit einem teilweisen Umstieg verwechseln, bei dem man neue Werkzeuge bekommen hat, die auch den Status verbessern (das „Belohnen“ durch bessere Werkzeuge ist ein Hauptgrund, warum so verzweifelt an Werkzeugen festgehalten wird und hat fatale Folgen in Sachen Verbesserung der Arbeitsprozesse, die über lange Zeit stabil waren, heute aber immer dynamischer werden).

Dass es etwas mit Gruppendynamik zu tun hat, kann auch gesehen werden, dass bestimmte Kombinationen von Teammitglieder vorhersagbar zu dieser oder jener Lösung führen wird. Das funktioniert oft auch, wenn die Mitglieder des Teams sich noch nicht kennen, aber alle Mitglieder dem bekannt sind, der das Team zusammenstellt. Und es geht sogar soweit, dass man sagen kann, welches Team bei welchem Part in Schwierigkeiten geraten wird. Wird diesen Entwicklungen nicht vorgebeugt, dann klappt das über Jahre. Es gibt ein Projekt, für das ich eine Vorhersage des Verlaufs für vier Jahre gab, sie trafen alle zu – gut, ich muss zugeben, das stimmt nicht ganz, denn zwei Jahre lang wurden die Übereinstimmungen als Zufall abgetan, dann war es ihnen zu blöd geworden, und sie haben eine Entwicklungspause eingelegt, von diesem Moment an lagen meine Vorhersagen genau um diese Pause daneben.

Fast nicht aufzufangen ist, wenn sich Leute finden, die sich gegenseitig darin unterstützen, dass es dieses Lösung (die meist nur von einem bestimmten Werkzeug erledigt werden kann) und keine andere sein sollte. Aufgrund der Trägheit in grösseren Firmen, dauert es sehr lange, bis dieser Vorschlag getestet wird. Meist ist der Grund, warum das Werkzeug „damals“ vorgeschlagen wurde, niemandem mehr bekannt, doch der Wunsch das Werkzeug einzusetzen wurde kollektiv. Obwohl es mittlerweile sehr viel besser geeignete Werkzeuge geben könnte, wird das Werkzeug von damals angeschafft, In einer derart gruppendynamischen Situation wird überwiegend mit den Standards von gestern gearbeitet.

Als freischaffender Programmierer bin ich kein Angestellter. In der Regel werde ich engagiert, weil ich mir einen Namen gemacht habe, vorsichtige Auftraggeber testen mit einem Kleinstauftrag. Neben meinen Fähigkeiten wird auch immer der Betrieb bzw. die Abteilung getestet. Der erste Auftrag ist immer etwas, das man Probezeit beider Seiten nennen kann. Ich habe nur wenige male diesen ersten Auftrag nicht verlängert – aus gutem Grund (vorzeitig beendet wurde er nur zweimal, aus sehr gutem Gründen). Dem stehen mehrere 100 Aufträge gegenüber. Es ist selten, kann aber passieren. Gründe dafür sind z.B. gewesen: Die Beschreibung der Aufgabe und die tatsächliche Aufgabe waren so unterschiedlich, dass es unterschiedlicher nicht geht. Ein Auftraggeber war schlicht nicht beratbar. Selbst als die ersten „Vorhersagen“ sich bewahrheiteten, wurde bei jeder Entscheidung schlicht das Gegenteil des begründeten Vorschlags gewählt – das war so zuverlässig, dass ich nach kurzer Zeit einfach das Gegenteil von dem, was ich für das Beste hielt, vorschlug, es wurde mit schöner Regelmässigkeit für meinen Favoriten entschieden. Selbstverständlich war unter den Mitarbeitern bekannt, was mein Favorit war, aber dass man wegen solcher taktischer Spielchen offiziell das Falsche vorschlagen muss, macht einen entschieden zu angreifbar.

In dieser Firma wurden konstruktive Mitarbeiter, Mitarbeiter, denen das Projekt nicht die eigene Position wichtig war, dazu gezwungen, sich gegen die eigenen Interessen zu verhalten. Machtspielchen sind immer gegen das Firmeninteresse gerichtet. Und als Angestellter, das durfte ich erleben, beginnen diese Machtspielchen gleich bei dem ersten Bewerbungsgespräch.

An dieser Stelle ist es Zeit eine klare Aussage zu machen: Wann immer ich zu einem Projekt gerufen wurde, um im eine „letzte Chance“ zu geben, war die erste Aufgabe, Machtspielchen abzustellen und eine konstruktive Arbeitsumgebung zu schaffen. Die zweite Aufgabe war immer die Teile des Codes, die unter dem Eindruck der Machtkämpfe entstanden sind, zu identifizieren und sie durch „vernünftigen“ Code zu ersetzen.

Was sind Machtspielchen?

Abgesehen von den offensichtlichen, ist die Abfrage von auswendig gelerntem (oder lernbarem) Wissen ein solches Machtspiel. Es fällt nicht auf den ersten Blick auf, aber man favorisiert eine bestimmte Gruppe von Bewerbern – Bewerber bestimmter Schulen und Umgebungen werden indirekt bevorzugt. Das macht es sehr wahrscheinlich, dass Freunde es „schaffen“ werden und da es sich herumspricht, verzerrt es jede Bewertung.

Da hier nicht die Rede von Arbeiten ist, bei denen Auswendiglernen eine effektive Arbeitsmethode sein könnte, ist das Abfragen solches Wissens auch nicht hilfreich. Der Bewerber lernt: „Show“. Effektive (besser: zu leistende) Arbeite reduziert sich auf Rituale, die erfüllt werden müssen – das löst keine einzige Aufgabe, aber sie sind abhakbar und das entlastet (scheinbar). Wieder wird der bevorzugt, der die Rituale gelernt hat. Das ist eine effektive Methode uneffektiv zu werden. Und da nur das Spiel mitgespielt werden muss, leistet auch niemand mehr. Eine Firma, die mit solchen Ritualen gesegnet ist, wird nur unter Einbindung externer Kräfte effektiv werden – wenn diese nicht mit diesem Mass gemessen werden.

Man kennt das „Abfragen“ von der Schule her. Aber die Schule ist nicht das Leben – und auch nicht die Arbeit. Die Schule legt „Grundlagen“ (ist aber auch ein erstes Machtspiel), ihr Ziel sollte sein, das Wissen zu vermitteln, damit im Leben der Weg von A nach B gefunden werden kann. Die Schule sollte die Fähigkeit vermitteln, im Dschungel der Möglichkeiten einen Weg zu finden, wenn sie nur Grundlagen abfragt, dann verfehlt sie das Ziel. Ebenso die Firma, die auswendig lernbares Wissen abfragt. Sinnvoller wäre es zu testen, ob der Bewerber ein gutes Gedächtnis hat, doch auch das kann durch vermitteln von Memotechniken aktive variiert werden.

Das wirklich Unangenehme an diesem Vorgehen ist aber, dass man die besser geeigneten ausfiltert. Man fragt das Wissen ab, das einem selbst bekannt ist. Sicher sortiert man damit Leute aus, die unterlegen sind – aber eben auch die, die überlegen sind.

Diese Praxis ist ein erstes – und sehr effektives – Machtspiel, weil es sichert, dass man sich keine Konkurrenz ins Haus holt und Freunde und Bekannte, die ähnlich denken. Der Effekt davon ist, dass nur Aufgaben gelöst werden können, die diesem Wissen entsprechen (hier ist die Rede von Schul- (quasi Basis-) -wissen, neue Produkte werden so praktisch ausgeschlossen, das Vorhandene kann variiert werden, alles andere geht nicht, da es den Auswahlkriterien widersprechen würde. Die Mitarbeiter sind brav und auf Linie – ein scheinbar schönes Arbeitsklima, ein ineffektives Arbeitsklima, in dem sich alle gegenseitig auf die Schulter klopfen und das Bestehende verteidigen, das ist definitiv nicht im Sinne einer Firma – es sei denn, sie will nur bewahren.

Der erfolgreiche Innovationsschutz der Firmen, die bestehende Produkte schützen wollen, beginnt in den Schule und wird über die Personalbüros bzw. Einstellselektionen in die Firmen getragen. Eine Firma muss da nicht mehr viel machen, das ergibt sich von selbst.

Neben dem Abfragen (und der vielleicht unbewussten Nivellierung der Bewerber) ist das zweite unnötige Verfahren, die Abfrage, welche Werkzeuge dem Bewerber bekannt sind. Tut man das, dann gesteht man indirekt nur ein, dass ungeeignete Werkzeuge eingesetzt werden, Werkzeuge, die einen massiven Einfluss auf den Arbeitsprozess haben. Wenn die Arbeit von den Werkzeugen dominiert werden, dann kann nur herauskommen, was die Werkzeuge hergeben. Das ist ein bisschen so, als ob man sagen würde: „Mein Lehrer hat mir für diese Sache keine Lösung beigebracht – er ist schuld“.

Eine Firma tut gut daran, die einfachsten Werkzeuge einzusetzen. Auch wenn die Regel gilt, dass es ein Alleinstellungsmerkmal ist, wenn man das Komplexe beherrscht. Schaut man genauer hin, setzten diese Leute meist die einfachsten Werkzeuge ein, denn sie schränken nicht ein. Es ist wichtig, dass die Arbeit unterstützt wird, es ist schlecht, wenn man dafür ein Studium benötigt.

Wirklich heftig wird es, wenn die Werkzeuge dann gegen ihren eigentlichen Sinn eingesetzt werden. Erfahrungen muss man machen, deshalb lasse ich das – für kurze Zeit – meist zu, nur, wenn aktuell die Prioritäten woanders liegen, dann wird es verschoben – wie alles andere. Zulassen muss ich es, wenn Gruppendynamik am Markt herrscht. Wenn die Parole umgeht: „So machen wir das in Zukunft“, dann würde ein erfahrener Marktteilnehmer wissen, dass praktisch jeder andere Weg besser ist. Aber die Gruppendynamik bremst sie aus.

Die meisten Firmen bremsen sich durch diese Gruppendynamiken aus. Um es verstehen zu können, hier ein Beispiel.

Es gab immer wieder Nachfragen, warum ich nicht in Gespräche der Bewerber gehe sondern immer nur das unverbindliche Gespräch / Plausch im Umfeld, den Kaffee davor oder danach, mit den Bewerbern suche. Die Antwort ist einfach: Weder die Selbstdarstellung der Firma, noch die des Bewerbers ist relevant; selten ist das folgende Frage- / Antwortspiel aussagekräftig, es ist einfach nur ein Ritual, die Schamanen werden gewinnen, die Macher gefiltert. Im „zufälligen“ Gespräch (auch, wenn der Bewerber weiss, dass er mit einer, für die Einstellung relevanten Person spricht, zeigen sich nahezu alle Eigenschaften. In diesem Gespräch kann kaum ein Bewerber verheimlichen, wie es um seine Aufnahmefähigkeit steht, ob er sich der Aufgabe stellt oder das Ritual sucht, ob er sich für die wahrscheinliche Aufgabe eignet oder ob er für eine andere Aufgabe besser geeignet wäre, man erkennt, was er will, kann und wohin er will.

Ca. zwanzig Minuten lang, kann sich ein (geübter) Autofahrer verstellen, danach zeigt sich, wie er im Alltag fährt. Im Gespräch ist das ähnlich. Von der halben Stunde, die ich pro Anwärter aufwende, sind deshalb die letzten 10 Minuten die informativsten – dennoch kann ich das Gespräch so umbauen, dass die wichtigen Fragen an ganz anderer Stelle gestellt werden, sich darauf einstellen ist aufgrund der grossen Kombinationsmöglichkeiten und den unterschiedlichen (unbekannten) Gewichtungen, fast nicht möglich. Man kann sich aber selbst verraten.

Einmal habe ich in einer Firma den Vorschlag gemacht, dass für das neue (umfangreiche) Projekt die Auswahl der Bewerber durch ein „Bewerberprojekt“ zu treffen. Die Bewerber werden für eine gewisse Zeit eingeladen, bekommen eine entsprechende Infrastruktur (die darf ruhig mager ausfallen) und eine völlig abwegige (sicher nicht Produktive) Arbeit gestellt, die sie in der gegebenen Zeit nicht lösen können. Es kommt nicht darauf an, dass sie es schaffen, sondern wie sie mit der Situation umgehen und was dabei heraus kommt. Sie werden dabei ständig beobachtet (das ist für die Auswertung nötig, denn selbst wenn direkt neben jedem Bewerber ein Beobachter stehen würde, wären das nur subjektive Daten). Die Auswertung zeigt die Stärken und Schwächen der Bewerber auf, man hat sehr gutes Material, um die besten Teamkombinationen für den Anfang etc. zu ermitteln. Hat man ähnliche Kenntnisse über die Firmen, Abteilungen und Mitarbeiter, kann mit überraschend wenig Aufwand, gemessen an den tausenden Bewerbungsgesprächen, die täglich stattfinden, sehr gute Ergebnisse erzielt werden.

Die Firma hat das für den internen Stellenmarkt durchgeführt und obwohl sehr gute Ergebnisse erzielt wurden, wurde es verworfen. Die Argumente waren: Für eine Firma zu teuer. Dazu werden keine Personaler benötigt. Du kannst das, wir könnten das nicht; wir bräuchten Psychologen und so weiter und es würde doch nicht dasselbe dabei herauskommen. Als Dienst würden sie es aber nutzen.

Den Wink mit dem Zaunpfahl habe ich damals nicht ernst genommen, denn, wenn das für die Allgemeinheit aufgezogen werden sollte (nur so wäre es sinnvoll), wäre für einen unpolitischen Mensch (ja, das war ich einmal und wäre es heute sehr gern wieder) wie mich, zu viel politische Arbeit nötig und zudem hatte ich einen vollen Terminkalender für die nächsten drei Jahre. Danach geriet es in Vergessenheit.

Auch heute wäre ich skeptisch, das einzige, was ich mir vorstellen könnte, wäre eine Art „Bewerbung auf der Messe“ Testlauf in dem sich Personen und Firmen bewerben und unter die Lupe genommen werden können. Angenommen, es bestätigt sich, wäre das Resultat eine Datenbank, in der sich die Qualitäten der Firmen, deren aktuelle Team (incl. Ziele, Zeitrahmen und Status) und die Mitarbeiter mit ihren Stärken und Schwächen gelistet sind. Ein Team zusammenzustellen wäre plötzlich sehr viel einfacher, weil man sehr zielorientiert vorgehen kann.

Ich konnte mir bereits damals beim besten Willen nicht vorstellen, dass jemand diese sensiblen Daten freigibt, heute wäre das sicher noch schwerer. Man stelle sich das vor: Eine Datenbank, aus der alle Stärken und Schwächen aller Firmen, aller aktuellen Projekte mit Status und die Persönlichkeitsbilder von Bewerbern steht. Einer hatte das mit einem Schulterzucken und den Worten: „’Die‘ wissen doch eh alles“ abgetan (das erstaunte mich doch), die meisten aber lehnten es erwartungsgemäss ab – haben die mir einen Gefallen getan?

In der Anfangsphase waren die Projektvermittler ein paar Kollegen von früher, die dadurch aufgefallen waren, dass es leicht war, mit ihnen ins Gespräch zu kommen, Sie kannten die Firmen, die Projekte, das geplante Team und wussten, wer da gut hineinpasst, riefen die zwei drei Kandidaten an und der Fall war erledigt. Heute leben mehrere tausend Menschen vom bestehenden Verfahren, würden die alle arbeitslos? Nein, sie würden effektiver aber, da Projekte erfolgreicher werden als heute, gäbe es auch mehr. Das gelingt aber nur, wenn einige andere Praktiken geändert werden: Es ist üblich seine Mitarbeiter mit den Worten zu motivieren: „Das ist das einzige Projekt, das wir haben, erledigt es zügig.“ Der Effekt ist, dass es ein unendliches Projekt wird, weil keiner arbeitslos wird. Sagt man das anders, dann wird das Projekt zügig erledigt werden: „Das ist ein Projekt, mit dem wir – die Firma und Mitarbeiter – beweisen können, dass wir das können. Beweisen wir das, haben wir gute Aussichten auf Nachfolge Projekte – bei diesem und bei jedem anderen Kunden, die wir bereits haben und die wir durch diese Arbeit gewinnen werden“. Lügen werden erkannt werden – so einfach ist das also nicht, denn Worte und Taten bilden Vertrauen, Misstrauen entsteht, wenn das nicht passt – und das kann jeder schnell erkennen, denn es betrifft ihn selbst.

Mitarbeiter aus den Personalbüros beklagen das „Mogeln“ der Kandidaten. Böse Zungen sagen spontan: „Wen wundert `s, das sind sie von der Schule her gewohnt“. Betroffene sagen, dass „das System“ das so will, es geht nicht um Leistung, es geht nur darum, ein Spiel zu gewinnen, indem keiner sauber spielen kann. Begründet wird das damit, das es nur darauf ankommt, auf `s Stichwort das Erwartete zu sagen (es sei dahingestellt, ob dem wirklich so ist), die ersten (wollen den Job gar nicht) bewerben sich, um die richtigen Antworten zu finden und geben ihre Erkenntnisse weiter.

Wieder werden Netzwerke geschaffen und unterstützt.

Zusammenfassung:

Viele Firmen machen sich selbst das Leben und die Bewerberauswahl schwer. Einmal versuchen sie den Bewerber zu vermessen – kein Psychologe würde sagen, dass er nach einem kurzen Gespräch und dem Werdegang des Bewerbers mehr als Stichpunkte hat, in die er weitersuchen würde.

Programmieren hat etwas mit Verinnerlichung von Aufgaben und Prozessen zu tun (das sieht man auch daran, dass der „Powercoder“ am besten zu hause arbeitet oder, wenn es unbedingt vor Ort sein muss, seine eigene Hardware mitbringt). Jeder hat seinen eigenen Stil und jeder kämpft an unterschiedlicher Stelle mit seinen Werkzeugen und Lösungen. Das kann man nicht abfragen. Schlimmer ist aber, dass man nicht nur die „Schlechten“ sondern auch die „Guten“ auf diesem Weg aussortieren muss, Netzwerke unterstützt, die nur einheitliche Situationen lösen können und die Flexibilität der Teams nahe Null rücken.

Es entsteht dadurch eine Situation, in der die Mitarbeiter nach immer neuen Werkzeugen fragen und die Lösungen auf die Werkzeuge verlagern.

Eine Firma, sollte daraus ihre Schlüsse ziehen: Die einfachsten Werkzeuge sind komplexen vorzu ziehen, ein internes, sehr einfach handzuhabendes Werkzeug, das die Werkzeuge dritter steuern kann, sollte zur Verfügung gestellt werden. Das ermöglicht den Biss und die Möglichkeiten des Probanden im Bewerbungsgespräch zu klären, das erlaubt treffendere Auswahlen und geht schneller und zuverlässiger, als die Mittel, die sich meist nur als mässig zuverlässig erweisen.

Projektler sind keine Angestellten. Das Angestelltenbewerbungsgespräch wird bei diesen nicht funktionieren. Das vorgestellte Gespräch ist für beide geeignet. Reduziert eine Firma dann noch die Komplexität der Werkzeuge bzw. setzt sie auf einen sehr einfachen Prozess, dann steigt die Zahl der verwendbaren Bewerber an, es werden Bewerbungs- und Versorgungsnetzwerke (beides ist hinderlich für die Flexibilität und Breitbandigkeit der Lösungen und setzt auf Lösungen durch Werkzeuge (für die dann Spezialisten eingestellt werden etc.)). Auch wird das Mogeln bei der Bewerbung unterbunden, da persönliche Gespräche nur sehr schwer manipuliert werden können – wenn Gefühle gezeigt werden dürfen.

Advertisements

From → Uncategorized

Schreibe einen Kommentar

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: