Ich habe noch einen Fehler, den man in Bewerbungsgesprächen vermeiden sollte: wenn man in den Bewerbungsunterlagen wichtige Projekte aufführt (z.B. Diplomarbeit, Praktika oder auch Hobbyprojekte), dann sollte man auch etwas dazu erzählen können. Ich habe in den letzten Monaten mehrfach mit Bewerbern gesprochen, die noch nicht mal grundlegende Angaben zum Projekt machen konnten – z.B. was für eine Entwicklungsumgebung verwendet wurde. Und das zum Teil bei Projekten, die noch nicht mal drei Jahre in der Vergangenheit lagen.

Mir fallen dafür nur wenig schmeichelnde Erklärungen ein:

* Es war ein Gruppenprojekt und der Bewerber hat sich vom Team durchschleppen lassen, ohne selber einen nennenswerten Beitrag zu leisten.
* Das Projekt war nicht wirklich wichtig – eine kleine Nebensache, die man sich nicht merken muss.
* Der Bewerber ist unkonzentriert und hat ein sehr schlechtes Gedächtnis.

Sicher gibt es noch weitere – neutralere Erklärungen. Und wenn es das einzige Problem ist, dann ist das auch kein k.o. Kriterium. Aber es ist auf jeden Fall ein negativer Punkt, den man leicht vermeiden kann. Einfach zu Beginn der Bewerbungsphase noch mal die alten Unterlagen ansehen oder sich das Projekt anderweitig noch mal vor Augen führen. Falls das nicht klappt, würde ich mir überlegen, das Projekt ganz aus den Bewerbungsunterlagen zu streichen.

Heute bin ich durch Zufall über einen älteren Blog Beitrag von Steven Sinofsky gestolpert: „Management Clichés That Work„. Da er auf diesem Gebiet als (ehemaliger) verantwortlicher Manager für Windows und Office viel Erfahrung haben sollte, habe ich den Beitrag natürlich gelesen. Ein paar Punkte daraus möchte ich hier aufgreifen.

Sinnvollerweise liest man erst den Beitrag von Steven Sinofsky. Anschließend geht es hier weiter…

Promise and deliver: Für den Teamleiter ist es wichtig, dass die Entwickler realistische Schätzungen abgeben. Deshalb bin ich genauso wie er der Meinung, dass die Masche “under promise and over deliver” (weniger zusagen als man leisten kann und am Ende des Projekts deshalb mehr abliefern als gefordert wurde) schlecht ist. Seine Begründung finde ich nur unzureichend. Das Problem bei dieser Vorgehensweise liegt für den Manager darin, dass er nur schlecht planen kann. Das Problem für den Entwickler wiegt noch schwerer: über fast die gesamte Projektlaufzeit wird er als wenig leistungsfähiger Mitarbeiter eingestuft. Die Erleichertung am Ende – „er hat ja doch einiges abgeliefert“ macht meiner Meinung nach die über längere Zeit aufgebaute Meinung nicht wett.

Richtig ist es (meiner Meinung nach), eine möglichst realistische Schätzung über die erreichbaren Ziele abzugeben. Gemeinsam mit einer Risikoabschätzung, was mindestens erreicht werden kann. Es ist die Aufgabe des Managers, sich Gedanken darüber zu machen, welche Zahlen nach außen kommuniziert werden. Dazu muss er aber möglichst realistische Zahlen haben. Wenn der Entwickler sich durch übermäßig hohe Sicherheitszuschläge vor Enttäuschungen schützen will, ist das unaufrichtig gegenüber der Firma und dem Team.

Diese Forderung funktioniert natürlich nur dann, wenn der Manager im Falle unerwarteter Probleme und nicht erreichter Ziele seine Verantwortung nicht einfach auf den Entwickler abschiebt. Er hatte die Zahlen und kannte die Risiken. Wenn er das nicht passend nach außen kommuniziert, muss er dafür auch selber die Verantwortung übernehmen.

Make sure bad news travels fast: dieser Punkt geht Hand in Hand mit dem bereits gesagten. Wenn die Schätzung aufgrund unerwarteter Gründe nicht aufgeht, dann muss man es auch so früh wie möglich kommunizieren. Nur dann hat der Manager die Möglichkeit Veränderungen vorzunehmen. Im schlimmsten Fall, dass der Releasetermin frühzeitig verschoben wird.

Für den Entwickler ist es hier wichtig, dass er sich nicht selber belügt. Der lustig gemeinte Satz „ein Softwareprojekt ist über 80% der Laufzeit fast fertig“ hat einen ernsten Hintergrund. Wenn ich nicht erkennen will, dass ich mit meinen Terminen im Verzug bin, kann ich es auch nicht weiterleiten. Mittelfristig ist so etwas für einen Entwickler ein ernsthaftes Karrierehindernis – er wird von seinem Manager ständig als Projektrisiko angesehen. Und dieses negative Gefühl überdeckt einen Teil der Leistungen.

Writing is thinking: es ist meiner Meinung nach offensichtlich, dass man beim Niederschreiben von Gedanken und Plänen gezwungen ist, tiefer über ein Problem nachzudenken. Wenn man einen Plan nur „im Kopf“ hat, kann man sich leichter selber beschummeln und offensichtliche Lücken leichter übersehen. Sobald man es schreibt, bekommt es eine andere Qualität. Damit ist nicht gemeint, dass man ständig umfangreiche Reports schreibt und nicht mehr zum Arbeiten kommt. Einfach in ein paar Sätzen die wichtigen Punkte aufschreiben und bei Bedarf noch ein paar Handskizzen reichen oft schon aus.

Noch besser ist es, wenn man es jemand anderen erklärt. Wenn ich es nicht erklären kann, habe ich es auch nicht verstanden. Damit ich es erklären kann, muss ich besser darüber nachdenken. Ich glaube, dass ein Teil des Erfolgs von Teamarbeit darin liegt, dass man seine Gedanken ständig erklären muss.

Practice transparency within your team: ein Softwareentwickler ist kein Einzelkämpfer in einer dunklen Höhle. Er ist ein Teamplayer – andere sind auf ihn angewiesen und er ist auf andere angewiesen. Und schon eine einzige Primadonna kann ein ganzes Team zerstören.

Don’t ask for information or reports unless they help those you ask to do their jobs: eine wichtige Aufgabe des Manager liegt darin, dafür zu sorgen, dass sein Team möglichst gute Arbeitsmöglichkeiten hat und somit die maximale Leistung bringen kann. Das ist keine reine Menschenfreundlichkeit sondern auch ganz egoistischer Selbstzweck. Ein egozentrischer Manager, der seine Eitelkeiten bedingungslos über sein gesamtes Team stellt, ist ein unfähiger Manager und gehört ausgetauscht.

Don’t keep two sets of books: den Vorgesetzten über den Projektfortschritt zu täuschen ist ein Verhalten, welches fast zwangsläufig zu Problemen führt. Ich glaube nicht, dass man das noch weiter erläutern muss.

Never vote on anything: hier bin ich abweichender Meinung. Vielleicht ist seine Einstellung auch der amerikanischen Eigenart geschuldet, dass man ein offenes Nein vermeiden sollte weil es unhöflich ist. Es gibt nun mal Situationen in denen alle Argumente ausgetauscht wurden, jeder hat die Position der anderen verstanden und trotzdem kommt man zu unterschiedlichen Ansichten. Hier kann es schon sinnvoll sein, einfach mal abzustimmen. Die Mehrheit hat nicht immer recht – aber wenn viele kluge Leute anderer Ansicht sind als ich es bin, dann ist es ein Grund, die eigene Position nochmal ernsthaft zu überdenken. Am Ende muss der Leiter entscheiden – er muss es schließlich auch verantworten.

When presenting the boss with n alternatives he/she will always choose option n+1: Autsch – das geht gegen die „pointy haired bosses„. Wenn der Vorgesetzte nicht in der Lage ist, die Möglichkeiten zu beurteilen, ist das eine Nothilfe. Ein normaler Manager möchte hier lieber eine ehrliche Liste der Möglichkeiten und Risiken haben. Niemand möchte gerne manipuliert werden, die Entwickler nicht – und die Manager auch nicht.

Products don’t ship with a list of features you thought you’d do but didn’t: wenn ein Feature so unwichtig ist, dass es ständig von anderen (neueren) wichtigen Features verdrängt wird, dann sollte man auch konsequent sein und es streichen. Sonst kommt man irgendwann in die Verlegenheit, dass man an unwichtigen Dingen arbeitet, „weil sie schon so lange da liegen“ – statt an den wichtigen Themen zu arbeiten. Es ist auch ehrlicher gegenüber dem Stakeholder dieses Features – lieber ein Ende mit Schrecken als ein Schrecken ohne Ende. Die Ausnahme hier: wenn es dem Einreicher mehr um persönliche Eitelkeiten als um das Produkt geht, kann es „humaner“ sein, den Featurewunsch in einer dunklen Ecken verschimmeln zu lassen als einen Grabenkrieg zu führen.

Durch meine Arbeit als Entwicklungsleiter führe ich natürlich auch eine größere Anzahl von Bewerbungsgesprächen durch. Dabei sieht man immer wieder bestimmte Muster, die einen Entwickler in eine Sackgasse führen. Ich kann natürlich nur über Probleme sprechen, die mir negativ auffallen. Aber ich vermute, dass diese Punkte auch bei anderen Firmen problematisch sind.

1. Falle – Unaufrichtige Bewerbungsunterlagen

Um es klar zu stellen – ich erwarte nicht, dass sich ein Bewerber in den Unterlagen selber schlecht macht. Und es ist legitim, sich in einem möglichst guten Licht darzustellen. Mit „unaufrichtig“ meine ich auch nicht gefälschte Zeugnisse. Das ist kriminell und muss nicht diskutiert werden.

Mit unaufrichtig meine ich stark übertriebene Fähigkeiten. Wenn ein Bewerber sehr gute SQL Kenntnisse angibt, dann erwarte ich zumindest ein solides Wissen über die Basics dieses Fachgebiets. In diesem Fall sollte man nicht mit der Frage „Was ist ein JOIN“ überfordert sein.

Eine Fehleinschätzung kann man durchaus akzeptieren. Wenn sich hier aber ein Muster abzeichnet und es in mehreren Gebieten massive Abweichungen in der Bewertung der Fähigkeiten ergibt, stellt sich mir die Frage, ob es der Bewerber allgemein nicht so genau mit der Wahrheit nimmt. Dann ist er für unsere Firma nicht geeignet.

Man muss nicht unbedingt bösen Willen unterstellen. Es kann ja sein, dass der Bewerber einfach nur ein wenig realistisches und überaus positives Selbstbild hat. Aber auch dann kommt er für eine Anstellung nicht in Frage. Ich hätte dann einen mittelmäßigen Angestellten, der ständig mit seinem Einkommen und seinen Karrieremöglichkeiten unzufrieden sein wird.

2. Falle – absterbende Nischen-Technologien

Es gibt auch heute noch eine große Anzahl von COBOL Arbeitsplätzen und als COBOL Entwickler wird man noch einige Zeit gutes Geld verdienen können. Ob es Spaß macht, ist eine andere Frage. Ich behaupte einfach mal, dass COBOL zwar ein absterbender Ast ist, aufgrund seiner weiten Verbreitung aber immer noch keine Nische ist.

Schwieriger wird es bei exotischeren Technologien, wie z.B. Mumps, Progress, Dataflex…

Wenn man in einem Betrieb nur mit so einer Umgebung arbeitet und dann den Job wechseln muss oder will, hat man ein kleines Problem. Daraus wird ein großes Problem, wenn man sich nicht zumindest privat mit anderen, moderneren Systemen auseinandergesetzt hat.

Natürlich kann man argumentieren, dass sich ein guter Entwickler in jede Programmiersprache (schnell) einarbeiten kann. Die Schwierigkeit liegt darin, dass ich im Bewerbungsgespräch kaum herausfinden kann, ob es sich um einen guten Entwickler handelt. Ein Jobangebot wäre mit einem hohen Risiko verbunden. Zudem finde ich persönlich einen Entwickler, der sich nur für die eine Programmiersprache im Job interessiert und nicht auch mal nach links und rechts schaut – nun ja, zumindest verdächtig.

3. Falle – Miniunternehmen oder one man shows

Ein Job als einziger Entwickler in einem Kleinstunternehmen direkt nach dem Studium kann durchaus reizvoll sein. Mangels Vergleichsmöglichkeiten ist man in der Firma der Held, der auf magische Art und Weise alle Probleme löst. Zumindest was das Thema Programmierung angeht, wird einem niemand in die Arbeit reinreden oder Vorschriften machen. Und man muss sich nicht für Fehler rechtfertigen, solange sie nicht allzu auffällig sind.

Das große Risiko dabei – man entwickelt sich nicht, oder zu langsam, weiter. Es gibt keine direkten Vorbilder, von denen man erfolgreiche Techniken erlernen könnte. Es gibt keinen Wettbewerb, keinen sozialen Druck, besseren Code zu schreiben.

Ich will damit nicht behaupten, dass man in so einer Position zwangsweise auf einem level mit begrenzten Fähigkeiten stehen bleibt. Aber das Risiko ist groß und ich habe es bei einigen Bewerbern so gesehen.

Fazit

Zu den Fallen 2 und 3 gibt es zum Glück einen Ausweg – man kann sich selber aktiv Weiterbilden. Im Internet nach best practices Ausschau halten, Tutorials lesen, in einem Open Source Projekt mitarbeiten. Wichtig ist die Interaktion mit anderen Menschen, anderen Denkweisen, anderen Vorgehensweisen. Das geht nur zum Teil während der regulären Arbeitszeit, zum Teil muss man es auch in der Freizeit machen. Das ist aber gut investierte Zeit in die Zukunft. Ein Entwickler ist nicht das Hollywood Klischee – er sitzt nicht 6 Monate im Keller um schließlich das revolutionäre Programm abzuliefern. Er muss mit anderen Menschen zusammenarbeiten und sich dabei selber auch weiterentwickeln.

Wenn man der Meinung ist, Computer sind nur während der Arbeitszeit ein Thema und in der Freizeit tabu, dann ist man in der IT Branche falsch. Schuhverkäufer wäre vielleicht eine Alternative. Aber möglicherweise muss man sich auch dort in der Freizeit über aktuelle Modetrends weiterbilden.

Zur Falle 1 gibt es einen einfacheren Ausweg: beim nächsten Mal eine realistischere Selbsteinschätzung und etwas mehr Ehrlichkeit.

Auf dieser Seite wird in Kürze mein Technikblog entstehen. Hier schreibe ich über Themen wie Software Engineering, „große“ Hardware und meine Spielereien mit embedded Systemen.

Ziel ist es, dass jede Woche mindestens ein Beitrag zu finden ist.