Archiv der Kategorie: Personalführung

Beispiele für Zielvereinbarungen

Allgemeines

Dieser Beitrag soll als kleine Hilfestellung für all diejenigen dienen, die sich mit der Findung von guten Zielen schwertun. Wer wie wir darauf hinarbeitet, dass die Mitarbeiter sich aus der Unternehmensstrategie die individuellen Ziele selbst ableiten und der Vorgesetzte nur noch unterstützende Funktion (z.B. Bereitstellen von Resourcen) ausüben muss, der wird zuerst viel kommunizieren und beraten müssen.

Während die eine Seite erfolgreicher Zielvereinbarungen die Verlagerung der Zieldefinition auf den Mitarbeiter selbst ist, ist die andere das Sichtbarmachen der operativen und strategischen Unternehmensziele. Damit einher geht natürlich das kontinuierliche Gespräch über die gemeinsame Unternehmenskultur. Beispielsweise wird es schwierig über monetäre Ergebnisziele zu sprechen, wenn die Kennzahlen nicht transparent zur Verfügung gestellt und erklärt werden. Nicht jeder Chef ist davon begeistert, wenn die Angestellten die genauen Margen von Aufträgen kennen.

  • Der Kern guter Ziele sind die S.M.A.R.T. Kriterien, auf die an dieser Stelle nicht weiter eingegangen werden soll.
  • Die Ziele drüfen sich nicht gegenseitig beeinträchtigen. Stattdessen sollen sie sich vielmehr gegenseitig beflügeln.
  • Die Erreichung des Ziels soll immer einen direkten oder indirekten Benefit für das Unternehmen haben (Stichwort Return on Invest).

 

Auf den Punkt gebracht: Die Mitarbeiter müssen um die Unternehmsziele wissen und diese mittragen. Ein gemeinsames Verständnis der Modalitäten und eine dazu passende Informationstransparenz sind ebenso elementar wie das Mitwirkenwollen des Einzelnen.

 

Beispiele für individuelle Ziele

  • Community Auftritte
    • Bis 31.12.18 hält der Mitarbeiter in den User Groups Berlin, Dresden, Leipzig, Chemnitz, Karlsruhe und Luzern Vorträge
  • Fachartikel
    • Bis 31.12.18 publiziert der Mitarbeiter 3 Fachartikel in Fachzeitschriften (z.B. in der dotnetpro)
  • Öffentliche Auftritte auf Konferenzen
    • Bis 31.12.18 hält der Mitarbeiter auf mind. 3 unterschiedlichen, kommerziellen Konferenzen Talks oder Trainings (z.B. DWX, Karlsruher Entwicklertage etc.)
  • Kommerzielle Workshops
    • Bis 31.12.18 generiert der Mitarbeiter durch Workshops einen Gesamtumsatz von mind. 20.000€
  • Fakturierung
    • Bis 31.12.18 fakturiert der Mitarbeiter durch Consulting mind. 800 Stunden.
  • Zertifizierung
Advertisements

Session Die 4 tierischen Menschentypen

Eine spannende Session mit dem Namen „Die 4 tierischen Menschentypen“ gab es dieses Jahr beim Developer Open Space. Das Video habe ich euch in meinem YouTube Kanal zur Disposition gestellt.

Leider bin ich ein wenig zu spät eingestiegen, sodass ein Teil der Einführung fehlt. Macht nichts, denn hier hat Tobias Beck das toll erklärt.

Feedback ist wie immer willkommen. Wenn euch das Video gefällt, dann teilt/liked diesen Beitrag. Wer noch den Link zum Online Self Test möchte, kann mir das in die Kommentare schreiben. Den Blog von Gregor gibt es hier.

Session Unternehmenswerte

Auf das Thema Unternehmenswerte konnte ich schon aus vielen Blickwinkeln schauen: Ob als Mitarbeiter, als Geschäftsführers, als Selbstständiger oder Dienstleister. Umso mehr hat es mich gefreut, dass Daniel Marbach dazu eine Session vorgeschlagen hat. Teilnehmer gab es reichlich. Ich hätte mir zwar  gewünscht, dass mehr aktive Teilnehmer ihre Meinung bei der nach dem Fishbowl-Konzept geführten Diskussion geäußert hätten, aber insgesamt war es eine wirklich gelungene Session. Die Aufnahme hat ein wenig mit Schwächen bei Bild und Ton zu kämpfen, aber unser Schüler Tim hat sein Bestes gegeben, um in der Nachbearbeitung die nötige Qualität rauszuholen.

Das Video darf man gerne als Einladung zur Diskussion verstehen. Deshalb halte ich hier die Punkte fest, die mir im Kopf geblieben sind:

Duzen/Siezen: Ein diskussionswürdiger Punkt, bei dem die Meinungen sicherlich auseinandergehen. In jedem Fall springen immer mehr Unternehmen auf den „Du-Zug“ auf. Klar ist aber auch: Die Anrede muss zur Unternehmenskultur passen. Ein Beispiel aus meinem Alltag sei genannt: Wenn unser Tim, Schüler, kürzlich erst 18 geworden, mit mir arbeitet, dann würde durch das Siezen aus meiner Sicht eine Hürde aufgebaut werden, die ihn bei der Arbeit weniger kreativ und in Bezug auf seine Lösungsansätze weniger „probierfreudig“ machen würde. Die Angst Fehler zu machen und sich an die Vorgaben des Chefs halten zu müssen, wird durch das Duzen einfach gemindert.

Kommunikationsnähe: Kommunikation findet bekanntlich zum Großteil nonverbal statt. Deshalb ist es umso wichtiger, eine möglichst hohe „Kommunikationsnähe“ zu erreichen. Sei es durch regelmäßige Treffen vor Ort (bei verteilten Mitarbeitern) oder durch Videokonferenzen. Chats und E-Mails sollten mehr durch die vorher genannten Punkte ersetzt werden. Für mich wird dabei einfach mehr Menschlichkeit vermittelt, die auch größere Meinungsunterschiede überwinden lässt.

Rituale: Halte ich ebenfalls für sehr effektiv. Seien es nun das Kickern oder Schachspielen in der Mittagspause, das Feierabend-Darts, das TGIF-Bierchen oder das Daily (als Videokonferenz!): Alles trägt zur besseren Kultur bei. Daniel hat mir einmal erzählt, dass bei Particular Videogespräche häufig mit einem „Kaffee-Gespräch“ über das allgemeine Befinden beginnen, bevor über Geschäftliches gesprochen wird.

Loben: Das ist nun mein persönliches Steckenpferd, wobei ich mit meiner Meinung vermutlich eine Minderheit vertrete. Ich halte Lob für Gift. Ein paar Argumente könnt ihr dazu im Video hören. Auf Twitter wurde dazu auch noch etwas gesagt. Dieser Link wurde in dem Kontext empfohlen. Weitere Informationen gibt es hier.

Persönlichkeitsanalyse: Das finde ganz spannend. Mehrere Firmen haben schon Persönlichkeitsanalysen für ihre Mitarbeiter durchführen und diese dazu schulen lassen, um Konfliktpotential zu erkennen und jedem Werkzeuge an die Hand zu geben, sich auf den Kollegen/die Kollegin einzustellen. Im Nachhinein hat mir noch ein Teilnehmer erzählt, dass bei ihnen die Projektgruppen nach dem Ergebnis zusammengestellt wurden. Alle, bei denen dies umgesetzt wurde, haben sich dazu positiv geäußert.

Wenn euch der Artikel geholfen hat, dann liked oder teilt ihn und hinterlasst einen Kommentar

Hinweis: Das Beitragsbild hat mir Andreas Richter zur Verfügung gestellt.

Programmieren – aber bitte nur von 8-17 Uhr

Zu meinem letzten Blogbeitrag Was ist denn bitte ein C# Experte gab es auf Twitter noch eine Diskussion darüber, ob der Job eines Entwicklers ein 8-17 Uhr Beruf ist. Dieser Beitrag soll eher dem Gespräch dienen, weil Twitter dazu nicht geeignet ist. Ich kann mir vorstellen, dass es hierzu bei 5 Personen 6 Meinungen geben wird. Konsequenterweise wird es deshalb in Betrieben auch häufig zu Problemen kommen, wenn völlig unterschiedliche Meinungen und Ansätze herrschen. Ich sage dazu:

Entwickeln ist keine 8-17 Uhr Tätigkeit.

Was ich aber damit meine: Es sollte keine feste Grenzen geben, da ich als Entwickler nicht auf Knopfdruck kreativ sein kann. Ein Maler kann genauso wenig immer von Montags bis Freitags von 8-17 Uhr Bilder kreieren. Ich treffe damit keinerlei Aussage darüber, ob mehr als 8 Stunden gearbeitet werden sollen. Oder weniger. Vielmehr glaube ich:

Nur Ergebnisse sind entscheidend, nicht die aufgebrachte Zeit

In dem Sinne: Work smart, not hard. Ich bin auf eure Meinungen gespannt!

Wie hole ich mein Team ab

Innovation bedeutet immer auch Veränderung. Der Mensch als Gewohnheitstier muss deshalb abgeholt werden, sonst bleibt er zurück. Quelle: FotoliaWelche Möglichkeiten hat eine Führungskraft hierfür?

Zunächst einmal gilt es Folgendes zu trennen:

  • Kann ein Mitarbeiter mit der Veränderung nicht Schritt halten?
  • Oder will er sich nicht verändern?

Während ersterem mit den richtigen Werkzeugen gut beizukommen ist, muss letzteres über Prinzipien und Werte gesteuert werden. Ausgenommen von der Regel sind Menschen, die nur deshalb nicht wollen, weil sie nicht können. Kann also beispielsweise jemand nicht tanzen, so wird er auch nicht auf die Tanzfläche wollen, nur um sich zu blamieren.

 

Prinzipien/Werte:

Ich bin der Meinung, dass Menschen ihre Arbeitsweise nur dann gewinnbringend ändern und sich produktiv am Prozess beteiligen, wenn sie von der Änderung selbst überzeugt sind. Demzufolge wird das Ergebnis bei einer typischen Command-and-Control Führung im besten Fall ausbaufähig sein. Eine aus meiner Sicht erfolgsträchtigere Herangehensweise könne diese sein: Bilde zwei Gruppen und lasse jedes Gruppenmitglied frei entscheiden, welcher der beiden Gruppen es beitritt. Die eine Gruppe setzt ein exemplarisches Projekt/Produkt gemäß der bisherigen Vorgehensweise um, die andere implementiert nach der neuen. Ein halber Tag ist dafür natürlich ungeeignet. Ein Monat ist der Geschäftsleitung eventuell zu kostspielig. Aber einen angemessenen Zeitraum benötigt es, um die gravierenden Prozessunterschiede zu Tage zu befördern. Eine unabhängige Instanz, z.B. der Product Owner, ein Externer oder eine Anwendergruppe, beurteilen das Ergebnis. Darüber hinaus sollten die Teams auch ihre Ergebnisse untereinander vergleichen. Einen wesentlichen Punkt würde ich noch aufnehmen: Bei dem Produkt sollten neue Anforderungen hinzu kommen und sich gegebenen Anforderungen ändern, um zu sehen wie anpassungsfähig beide Vorgehen sind. Unter der Prämisse, dass die neue Herangehensweise gewinnt und die Diskussion ernsthaft und konstruktiv geführt wurde, kann das Gros der Gruppe überzeugt werden. Die restlichen Skeptiker kippen eventuell durch Schlüsselfiguren, sogenannte Meinungsmacher, oder bei den ersten Erfolgen. Es ließe sich noch viel dazu sagen, aber ich möchte es an dieser Stelle dabei belassen und mit einem Zitat abschließen, welches meiner persönlichen Einstellung entspricht: “Die Führungskraft führt nicht über die Inhalte, sondern sie führt über die Emotionen […]” (Boris Gloger, S. 302, Produkte zuverlässig und schnell entwickeln).

 

Werkzeuge:

  • Retrospektive: Für mich das wertvollste Werkzeug überhaupt. Egal ob tägliche Einzelretrospektiven oder wöchentliche Gruppenretrospektive, wichtig ist: So häufig wie möglich, Ergebnisse festhalten und vor allem umsetzen. Mehr dazu hier.
  • Coding Dojos: Alle 1-2 Wochen für 2 Stunden. Erste spürbare Ergebnisse zeigen sich in kürzester Zeit. Ich arbeite gerade an einem Fachartikel dazu. Bis dahin schaut ihr hier.
  • Pair Programming: Super für die Vermeidung von Inselwissen und das Etablieren eines kontinuierlichen Wissenstransfers. Gerade bei Teammitgliedern, die sich schwer tun mit neuen Praktiken (z.B. TDD) geeignet oder mit heterogenen Teams aus Junior und Senior Developer. Für weitere Informationen schaut in den Wikipedia-Artikel.
  • Open Spaces / World Cafe: Interessante Konferenzformate zur Optimierung des Wissensmanagements. Einen Artikel dazu habe ich in der dotnetpro veröffentlicht.
  • Bloggen: Lässt sich vortrefflich mit der Retrospektive bündeln. Kann als Quelle für andere (und einem selbst) Teammitglieder dienen. Das Schreiben und Widerholen begünstigt auch den Lernprozess.
  • Scrum: Eine agile Methode zur Produktentwicklung, die die kontinuierliche Verbesserung fest im Prozess implementiert hat. Alle meine bisherigen Blogbeiträge zum Thema findet hier.
  • Communities: In nahezu jeder größeren Stadt gibt es dedizierte Communities, z.B. Scrum Stammtisch, .NET User Group, SQLPass, etc.. Ein Austausch mit Dritten ist immer hilfreich, v.a. wenn Entwickler in anderen Firmen die neue Vorgehensweise bereits erfolgreich anwenden.
  • Externe Consultants: Empfinde ich als besonders hilfreich um die anfänglichen Klippen zu umschiffen.

Abschließend sei noch gesagt, dass es eine Vielzahl an Werkzeugen gibt, jedoch muss das Tool auch zur Person bzw. der Gruppe passen. Pair Programming ist z.B. etwas, das nicht jeder Entwickler möchte.

Mich würde interessieren, wie bei euch Änderungen eingeführt wurden? Gab es Kollegen, die sich schwer damit taten? Wie hat die Führungskraft diejenigen abgeholt? Gibt es ein besonders hilfreiches Werkzeug, das bei euch Wunder bewirkt hat? Würde euch ein längerer Artikel mit konkreten Beispielen interessieren?

 

Edit 16.05.2014: Daniel Marbach hat mir ein interessantes Buch zu dem Thema empfohlen. Eine Rezension darüber wird folgen, da ich es inzwischen auf meinem Kindle habe.

Buchrezension – Scrum von Boris Gloger

Von Zeit zu Zeit stoße ich auf Bücher, bei denen es sich tatsächlich lohnt diese von Anfang bis Ende durchzulesen. So ein Buch ist Scrum: Produkte zuverlässig und schnell entwickeln von Boris Gloger .

Prädikat: Hohe Praxisrelevanz!

In über 300 Seiten bündelt der Autor sein Wissen zu einem hervorragenden Kompendium, das ich selbst unter anderem für eine Inhouse Schulung mit meiner Abteilung nutzen konnte. Die Praxisrelevanz wurde mir dabei so richtig bewusst, als auf mehreren Community Treffen (wie dem Open Space) genau die Fragen aufkamen, die Boris in seinem Buch angeht. Schon während dem Lesen passierte es mir deshalb immer wieder, dass sich neue Fragen bereits kurze Zeit später von selbst klärten. In einem Kapitel wird beispielsweise klar kommuniziert, dass eine Vision essentiell ist, am Anfang der Entwicklung stehen und dem Team deutlich vermittelt werden muss. Mit dem Hintergrund, dass wir an unserem hauseigenen ERP-System bereits seit vielen Jahren entwickeln, fragte ich mich, inwieweit dies auch auf bestehende Produkte zutrifft und wie dem Rechnung zu tragen sei. Bereits zwei Seiten später wurde mir die Frage beantwortet. Selbst von manchen fälschlicherweise als Nichtigkeit abgetane Feinheiten werden berücksichtigt: Der Begriff Team ist für sich nicht eindeutig und lässt in der Praxis in Gesprächen immer wieder Missverständnisse entstehen. Dabei ist nicht klar, ob mit Team alle am Produkt beteiligten Personen oder nur das Entwicklerteam gemeint ist. Schade ist an dieser Stelle nur, dass der Autor zwar bemüht ist, klar zu differenzieren, aber hin und wieder dieser Ungenauigkeit verfällt.

 

Schwerpunkt

In einer Rezension von Chip.de heißt es, dass der gefühlte Schwerpunkt auf Scrum in großen Organisationen liegt. Es ist richtig, dass der Autor stets bemüht ist Fragen, die in diesem Kontext aufkommen, zu beantworten. Persönlich sehe ich aber den Schwerpunkt auf der Philosophie, den Prinzipien und Werten hinter Scrum. Das zeigen zum einen die Verweise auf weiterführende Literatur. Leading Change, Start With Why, First, Let’s Fire all the Managers, Creativity under the Gun oder Die Idee des Management 2.0 sind nur ein paar Bücher, aus denen rezitiert wird. Zum anderen zeigen das die durchdachten Aussagen, die ich dermaßen deutlich bisher noch nirgends lesen konnte. Boris vertritt z.B. die Meinung, dass “Scrum seinen Ursprung nicht in der Lean Production hat. So richtig das ist – der Ursprung liegt im Wissensmanagement”. Weiter stellt er klar: “In Wahrheit handelt es sich bei Scrum also um eine Produktentwicklungsmethode und nicht um eine Projektmanagementmethode”. Im Subtext schwingt beim Lesen einfach mit, dass die Basics genauso durchdacht und in Frage gestellt wurden wie es für das Experten Know How der Fall ist. So verwundert es nicht, dass er auch gleich mit der typischen 3-Rollen-Gliederung in Scrum aufräumt und ein 6-Rollen-Konzept vorschlägt. Sicherlich etwas, das oft an Scrum kritisiert wird. Deshalb weiße ich an dieser Stelle explizit darauf hin, dass gerade die Anfangskapitel nicht übersprungen werden sollten, nur weil es sich um vermeintliche Banalitäten handeln könnte. Dort finden sich richtige Erkenntnisperlen.

 

Entwickler sind nicht außen vor

Als Developer freut es mich besonders, dass Boris auf Entwicklungspraktiken wie Continuous Integration, Test Driven Development und Configuration Management als essentiell und erfolgsentscheidend hinweist. Nicht nur hinweist, sondern dem Ganzen auch die nötige Anzahl Seiten widmet. Darüber hinaus wird auch von technischer Schuld und den damit einhergehenden Problemen gesprochen. Ich stelle immer wieder in Gesprächen mit Product Ownern oder Scrum Mastern fest, dass ihnen der Begriff Evolvierbarkeit und die dahinter lauernden Falle, besagte technische Schuld, nicht geläufig ist. An die geneigten Leser, denen der Begriff ebenfalls nichts sagt: Füllt diese Wissenslücke!

 

Wo Licht ist, ist auch Schatten

Weniger gefallen haben mir die Illustrationen und Bilder, welche zum einen in Deutsch, zum anderen in Englisch und wieder welche in beiden Sprachen beschriftet wurden. An einigen wenigen Stellen gelang es ihm nicht seine Gedanken klar genug zu formulieren, sodass ich ihn über Twitter oder über eine seiner Mitarbeiterinnen um Aufklärung bat (welche ich dann auch erhielt). Dabei handelt es sich nicht um subjektives Empfinden, da meine Kollegen die Aussage ebenfalls nicht verstanden. Darüber hinaus ist bei dem Buchkauf zwar eine kostenlose Ausgabe des eBooks im PDF Format enthalten, eine Kindle Ausgabe sucht man leider genauso vergebens wie eine epub- oder mobi-Version. Außerdem stieß ich auf mehrere Fehler in der vierten Auflage, darunter falsche Kapitelverweise und nicht mehr erreichbare Links. Diese werde ich dem Autor zukommen lassen. Vielleicht ringe ich ihm dafür ein kurzes Interview ab?!

 

Fazit

Lesen – von Anfang bis Ende!

Lebenslanges Lernen

Gerade in der IT-Branche ist es elementar sein Wissen kontinuierlich weiterzuentwickeln. Nicht umsonst findet sich in vielen Fachbüchern und Fachzeitschriften inzwischen die Aussage, dass die größte Herausforderung für den Vorgesetzten der Zukunft die Entwicklung hin zum Coach ist. Das heißt fungiert nicht länger selbst als fachlicher Entscheider, sondern er verhilft dem Mitarbeiter zu dieser Kompetenz. So wie der Fussball-Coach nicht selbst Fussball spielt, sondern den Spielern zeigt, worauf es ankommt und wie sie sich verbessern, damit sie im konkreten Spiel ihr Leistungspotential  eigenverantwortlich ausschöpfen. Hierzu mehr in einem späteren Blogbeitrag.

Der lernaffinste Mitarbeiter nützt nichts, wenn er nicht entsprechende Werkzeuge und Materialien an die Hand bekommt. Dazu benötigt es ein aufgeschlossenes Unternehmen, das den langfristigen Nutzen der dazu nötigen finanziellen Mitteln sieht und einen Vorgesetzten, der passende Angebote kennt. An dieser Stelle möchte ich einige Beispiele nennen, die in der IT der Firma heco zum Einsatz kommen:

eLearning: Ein hervorragendes eLearning Portal mit qualitativ sehr hochwertigen Video Trainings ist Pluralsight. Wir haben erst kürzlich dazu einjährige Subscriptions mit Offline Nutzung erworben, sodass die Kollegen die Inhalte offline unterwegs auf Handy, Tablet oder Laptop konsumieren können. Damit kann selbst die 20-minütige Zugfahrt produktiv genutzt werden.

eBook Reader: Inzwischen besitzt jeder IT-ler einen Kindle. Es kann oftmals sein, dass zunächst der Vorgesetzte aktiv und auf sinnvolle Bücher hinweisen muss. Bei uns stelle ich beim wöchentlichen Mittagessen typischerweise die Frage: “Liest gerade jeder an etwas?”. Die Kosten werden dabei vollständig übernommen, der Mitarbeiter liest im Gegenzug natürlich überwiegend in seiner Freizeit.

Zeitschriften Abos: Mit der Web and Mobile Developer, der Tec Channel kompakt und der dotnet Pro haben wir für alle 3 IT Bereiche jeweils ein Abo im Programm.

Unkonferenzen: Persönlich bin ich kein Freund von großen, handelsüblichen Konferenzen. Diese haben zwar z.B. für einen allgemeinen Überblick ihre Daseinsberechtigung, aber wir konzentrieren uns mehr auf sogenannte Unkonferenzen wie den Developer Open Space. Das Gespräch unter “Gleichen” die selbst die Inhalte festlegen und gleichzeitig dann auch erarbeiten ist enorm hilfreich.

Gruppen: Sei es die .NET User Group, die SQLPass, der Agile Scrumtisch oder die Social Media Night Stuttgart. Bei vielen Treffen sind wir vertreten. Die Treffen sind gänzlich kostenfrei (lediglich SMCST kostet 5€ pro Person). Unterstützt werden unsere Mitarbeiter durch Poolfahrzeuge und mit kürzerer Arbeitszeit, um ggf. auch bei längeren Strecken pünktlich kommen zu können.

Webinare: Viele Produkthersteller bieten Webinare an, welche wir oftmals im Kollektiv im Besprechungsraum auf der Leinwand konsumieren. Besonders Mindjet ist hier sehr aktiv.

Coding Dojos: Die Software-Entwickler bei uns halten regelmäßige Coding Dojos, d.h. interne Entwickler Trainings. Damit geht der Betrieb zunächst einmal in Vorleistung, denn die Zeit wird ja nicht für Produktivcode genutzt. Meiner persönlichen Erfahrung nach kann ich nur sagen, dass sich die Zeit definitiv lohnt.

Soziale Netze: Ein vielleicht ungewöhnlicher Punkt, aber soziale Netze sind für den Arbeit im Umfeld des Wissensmanagements ein unverzichtbares Werkzeug. Während in vielen Arbeitsstätten der Zugang gesperrt oder verboten ist, sind bei uns die Mitarbeiter aufgerufen aktiv mitzuwirken, um sich ein entsprechendes Netzwerk aufzubauen. Das schnelle Finden von Consultants, die kurze Info bei einem spezifischen Problem oder einfach Mal flugs die wichtigsten Eckpunkte in einem unbekannten Thema einholen; das alles geht mit Twitter & Co. 1,2,3. Das ist wesentlich effizienter und kostensparender als die Eigenrecherche, die sich schnell zu mehreren Stunden aufsummiert.

%d Bloggern gefällt das: