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.