Kombinat Softwareentwicklung

Wir sind noch immer beim Thema “Chef-Mitarbeiter” oder auch “Mitarbeiter-Chef” des vorhergehenden Beitrags.

Das Verhalten sei ungetrübt. Die Beziehung auch. Aber die Leistung stimmt nicht.

Jedenfalls sagt das der Chef über die Arbeitsergebnisse des Mitarbeiters. Oder auch der Mitarbeiter über die Aufgabenzuteilung oder die Vertretung nach außen/oben durch den Chef.

Eine bestimmte, konkrete Leistung kann man nur fachlich bewerten. Am besten ist es, wenn Mitarbeiter und Chef beide mit Fachkenntnis ausgestattet sind und es einen Maßstab gibt, auf den man sich einigen kann. Also beispielsweise der Chef eine Grundahnung von Java-Programmierung hat und der Mitarbeiter die Grundlagen des Projektmanagements kennt. So dass jeder die Welt des anderen wirklich verstehen kann. In der Praxis ist das selten der Fall. Daher die Probleme der unterschiedlichen Leistungserwartung.

Der Maßstab kann eigentlich nur ein anderer Mitarbeiter oder ein anderer Chef sei. Fachliteratur hilft nicht weiter. Externe Experten sind zwar manchmal hilfreiche Impulsgeber aber keine Dauerlösung für die tägliche Zusammenarbeit.

Deshalb sind Teams die Lösung: Es gibt von allen Kompetenzen mehrere Personen – also mehrere Java-Programmierer und mehrere Projektleiter oder Kundenbetreuer. Damit kann man immer vergleichen und hat einen plausiblen Maßstab schnell und kostengünstig zur Hand.

Einen Fehler darf man aber keinesfalls machen – und er ist enorm naheliegend: Regelmässig den Schwächsten rauswerfen. Auch wenn der eine Java-Programmierer regelmässig schwächere Leistungen als der Kollege und der eine Chef regelmässig schwächere Leistungen als der Co-Chef zeigt, dürfen sie nicht auf der Abschussliste stehen. Die Folgen auf das Betriebsklima wären verheerend – in einer Gruppe aus zwei oder mehr Personen ist immer (!!!) einer der Schwächere und die Abschussregel wird spätestens nach dem zweiten Abschuss jeder durchschaut haben.

Also einfach konstant schlechte Leistung tolerieren?

Selbstverständlich nicht. Jedenfalls nicht in der Privatwirtschaft. (In anderen Organisationsformen habe ich die Personalentwicklungsstrategien noch nicht verstanden.)

Worauf es ankommt: Laufende Verbesserung erreichen. Durch eigenes Bemühen als Mitarbeiter, ein besserer Java-Programmierer zu werden und als Chef, ein besserer Projektmanager/ Kundenbetreuer zu werden. Und durch Kommunikation zwischen Chefs und Mitarbeitern über genau dieses Thema. Ohne Schuldzuweisungen – sondern konstruktiv. Und durch gemeinsame Anstrengung. Wenn die Mitarbeiter erkennen, dass auch die Chefs noch üben, ist nichts verloren sondern viel gewonnen.

Und wenn alle bemerken, wie sie laufend besser werden…hat ein Unternehmen alle Voraussetzungen, ein echter Champion zu werden.

“Nehmen Sie die Menschen, wie sie sind, es gibt nämlich keine anderen.” soll Konrad Adenauer gesagt haben. Das sehe ich auch so.

Haben Sie sich schon einmal über Ihren Chef geärgert? Der Ihre Arbeit nicht gewürdigt hat?

Meine Erfahrung aus der Tätigkeit als Unternehmensberater seit 1986 ist: Jedes Unternehmen hat die Mitarbeiter, die es verdient.

Aber auch: Jeder Mitarbeiter hat den Chef, den er/sie verdient. Im Großkonzern gilt das nur eingeschränkt, da man die Strukturen gar nicht und die Menschen oft recht wenig beeinflussen kann. Im kleinen Unternehmen ist das anders, da kann man selbst ganz erheblich mitgestalten. Hierarchien sind nicht so ausgeprägt, die Leute sind leichter im Büroalltag zu treffen und verschanzen sich nicht hinter Statussymbolen, Fachjargon, usw.

Wer diese Gelegenheit zur Gestaltung nicht nutzt, ist erstens selbst Schuld und wird zweitens in einer größeren oder anderen Organisation auch nicht glücklich werden. Wechseln hilft nicht, das Problem wird dort wieder auftreten, da es Ihr persönliches Problem ist.

Was kann man tun?

Es hilft, sich Mühe zu geben – einerseits fachlich und andererseits zwischenmenschlich-kommunikativ.

Wenn erkennbar ist, dass Sie sich fachlich einsetzen, haben Sie eine sehr wichtige Basis gelegt. Darauf komme ich gleich zurück. Wenn Sie Ihre Unzufriedenheit gegenüber der Person, über die Sie sich ärgern ansprechen, bekommen Sie (beide!) die Gelegenheit, die (gemeinsame!) Situation aus einem anderen Blickwinkel zu erfahren. Unter der Annahme, dass die Beziehung nicht tiefgreifend gestört ist, wird sich daraus ganz sicher ein Erkenntnisprozess ergeben verbunden mit der Chance, auch ohne umfangreiche Maßnahmenkataloge und allein durch die Bewußtwerdung, eine Verbesserung der Beziehung und nachfolgend auch der Zusammenarbeit herbeizuführen.

Das funktioniert aber nur, wenn die sachlich-fachliche Basis stimmt. Wenn es dort tatsächliche Defizite geben sollte, werden diese immer in den Klärungsprozess hineinspielen und Schuldzuweisungen machen es schwieriger, allein über die Unzufriedenheit in der zwischenmenschlichen Beziehung zu sprechen. Verhalten Sie sich so, dass nicht schon Ihr Verhalten der Anlass für Unzufriedenheit ist! In diesen Punkt spielt auch die Leistungserwartung hinein – dazu komme ich in einem eigenen Beitrag.

Gelten diese Aussagen nur für die Blickrichtung Chef – Mitarbeiter? Nein, sie gelten in beiden Richtungen! Bitte lesen Sie die vorhergehenden zwei Absätze noch einmal vor diesem Hintergrund…

Das Jammern der Mitarbeiter über die Chefs ist genauso unangebracht wie das Jammern der Chefs über die Mitarbeiter. Also aufhören zu jammern und anfangen zu kommunizieren!

Mit Martin war ich von Freitag bis heute Mittag beim Tourismuscamp II in Eichstätt. Zusammenfassung: Jede Minute war wertvoll. Wir haben mit navando einen riesigen Schritt nach vorne gemacht. Insbesondere: Feststellen, was die Touristiker momentan beschäftigt und welche Ziele, Ansatzpunkte und Barrieren für Location Based Services im Tourismus bestehen.

Ein kleiner Nebeneffekt: Ich habe begonnen, zu Twittern. Warum? Twitter kann, in Verbindung mit einem Blog und einem Facebook-Account positive Rückkopplungseffekte erzeugen – das Gold des E-Commerce. Danke an Florian für seine Überzeugungsarbeit und Schilderung, welche Effekte hier wirken!

Mal sehen, ob Twitter meine Kommunikation verbessern kann.

Wie relevant sind Barcamps? Wie könnte man einen Impact Indicator entwickeln? Wie kann man die Qualität und die Reichweite der Inhalte eines Barcamps messen? Dazu haben wir in der letzten Session des zweiten Tages nachgedacht.

Wichtig war für mich der Gedanke, dass Barcamps eine Form des Transfers zwischen Wissenschaft und Wirtschaft sein können (43:12). Im Ergebnis bleibt es wohl die Aufgabe der Wissenschaft, aus den zahlreichen Fakten dieser Welt zu abstrahieren. Barcamps sind Realtime und mit zahlreichen Zwischentönen versehen – Ersteres ist für den Wissenschaftler kaum zu verarbeiten, wenn es nicht Zusammenfassungen gibt. Diese sollten als Blogartikel zurück verlinkt und insbesondere in’s Barcamp-Wiki gestellt werden.

CTO steht für Chief Technology Officer, also den technischen Leiter.

Er ist verantwortlich dafür, dass die technische Seite der Gründung optimal funktioniert.

Die folgenden Ausführungen beziehen sich hauptsächlich auf IT-Gründungen – sie sollten aber leicht auf andere Branchen übertragbar sein.

Was bedeutet “technische Seite”?

Sehr wichtig: Die richtige Entscheidung über die Systemarchitektur und die Auswahl der zugrundeliegenden Technologien. Ohne eine jahrzehntelange Erfahrung in der IT gar nicht so einfach. Mit einer ausgeprägten Stärke des CTO bei z.B. Datenbanken oder Java auch gefährlich, da nicht jede Technologie für jedes Problem geeignet ist.

Der CTO benötigt den Überblick. Was macht man mit welcher Datenbank, Programmiersprache, Präsentationstechnologie, etc.? Wenn er den Überblick noch nicht hat: Neugierde und die Fähigkeit, Wissensträger zu identifizieren und anzusprechen.

Noch wichtiger ist jedoch die Architektur der Plattform bzw. Software, die das Unternehmen heute beginnt, zu erstellen und die vermutlich mindestens 5 Jahre Bestand haben soll. Wie werden Module geschnitten? Welche Anwendungsfälle sind zu berücksichtigen?

Aber am wichtigsten ist es, Komplexität reduzieren. Hosting outsourcen. Standards bei Tools (Oracle?, AJAX?, Typo3?) und für die Entwicklungsprozesse (Lastenheft? Eclipse?, SVN? Trac?) schaffen. Routine entsteht nur dadurch, dass nicht alles jeden Tag neu erfunden wird. Effektivität entsteht durch Wiederverwendung. Sicherheit (und Teamspirit!) entsteht durch quaifizierte Mitarbeiter, die sich (in Grenzen) jederzeit ersetzen können oder gemeinsam knifflige Situationen meistern können. Ein Programmiererteam, das selbstständig Probleme lösen kann, entlastet den CTO – und genau das sollte ein guter CTO anstreben.

Was bedeutet “optimal funktioniert”?

Dass Systeme laufen müssen, ist klar. 99,99% uptime sind schnell gefordert und nicht für jeden Dienst erforderlich. Darum geht es zwar auch, aber nicht hauptsächlich.

Die schwerwiegenden Fehler entstehen häufig aus schlechten Prozessen in der Technik. Schlechter Code. Fehlende Reviews. Unzureichende Testprozesse. “Vergessene” Tests. Zusammenfassend: Organisatorische Versäumnisse, die ein Zusammenspiel der Menschen erlauben, das zu Fehlern führt.

In der Organisationstheorie gibt es den Gedanken, dass es ein Ziel von Organisation ist, von einzelnen Menschen unabhängig zu werden und die unvermeidlichen Fehler des Einzelnen zu kompensieren. Eine gute Organisation bringt sogar weitgehend unfähige Menschen zu Erfolgen!

Dieses ist die erste Hauptaufgabe des CTO.

Muss der CTO genial oder fleißig sein?

Beides. In der Startphase und bei jeder neuen Produktentwicklung wieder genial. Dazwischen fleißig, die angesprochenen organisatorischen Prozesse in der Technik im Detail zu beherrschen.

In der Startphase treffen sich häufig mehrere geniale Techniker, die mit Eifer eine neue Software entwickeln. Irgendwann kommt dann eine nicht so interessante Betriebsphase hinzu, in der das im Markt positionierte Produkt “am Leben erhalten werden muss” – also verlässlich funktioniert. Für wirklich geniale Entwickler, die Raketenbauer, eine eigentlich uninteressante Aufgabe.

Hier muss der CTO die richtigen Personalentscheidungen herbeiführen und das Team frühzeitig ergänzen. Es werden Techniker gesucht, die Qualität liefern können – und zwar täglich und ohne Ausfälle. Diese Lokomotivführer tragen Verantwortung und ihnen gebührt das Lob für den (technischen) Markterfolg. Ein guter CTO erkennt, wie er (sich und) sein Team personell ergänzen muss.

Dieses ist die zweite Hauptaufgabe des CTO.

In dem Sinne: Diese Qualitäten müssen aus Ihrem Businessplan erkennbar sein, den Sie in der kommenden ersten Stufe des Businessplan-Wettbewerbs Berlin-Brandenburg einreichen können.

Nehmen Sie am Basisseminar Nr. 3 “Gründer und Team” teil!