Empowered E-Book

Marty Cagan

• Herausgeber: Wiley-VCH GmbH
• Kategorie: Fachliteratur
• Sprache: Deutsch

Seitenzahl: 529

Veröffentlichungsjahr: 2022

Beschreibung

Was ist das Besondere an den Top-Tech-Unternehmen, wie Amazon, Apple, Google, Netflix und Tesla, das ihre konstante Innovationsleistung ermöglicht? Die meisten Leute denken, dass es daran liegt, dass diese Unternehmen auf eine besondere Art Talente finden und anziehen, die herausragend innovativ sind. Aber der wahre Vorteil dieser Unternehmen liegt nicht so sehr darin, wen sie einstellen, sondern vielmehr darin, wie sie es ihren Mitarbeitern ermöglichen, zusammenzuarbeiten, um schwierige Probleme zu lösen und außergewöhnliche Produkte zu schaffen. Das Ziel des Buches von Marty Cagan und Chris Jones ist es, Ihnen als Leiter des Produktmanagements, des Produktdesigns oder der Entwicklung alles zur Verfügung zu stellen, was Sie brauchen, um genau solch eine Umgebung zu schaffen. Als Partner der Silicon Valley Product Group arbeiten Marty Cagan und Chris Jones seit Langem daran, die besten Praktiken der beständigsten innovativen Unternehmen der Welt zu enthüllen. Als natürliche Ergänzung zum Bestseller "Inspiriert" geht das neue Buch direkt den Grund an, warum es den meisten Unternehmen nicht gelingt, das Innovationspotenzial ihrer Mitarbeiter wirklich zu nutzen. Der Schlüssel ist Führung bzw. Leadership. Das Buch behandelt: - was es bedeutet, ein leistungsstarkes Produktteam zu sein, und wie sich dies von den "Feature-Teams" unterscheidet, die von den meisten Unternehmen zur Entwicklung von Technologieprodukten eingesetzt werden; - die Rekrutierung und das Coaching der Mitglieder von Produktteams, zunächst zur Kompetenz und dann zum Erreichen ihres Potenzials; - Schaffung einer inspirierenden Produktvision zusammen mit einer erkenntnisgetriebenen Produktstrategie; - Umsetzung der Produktstrategie, indem man Teams mit spezifischen Zielen - zu lösenden Problemen - statt mit zu entwickelnden Funktionen betraut; - Neudefinition der Beziehung zwischen den Produktteams und dem Rest des Unternehmens; - detaillierte Beschreibung der Änderungen, die notwendig sind, um Ihre Organisation effektiv und erfolgreich auf wirklich fähige Produktteams umzustellen. Das Buch gibt Ihnen die jahrzehntelangen Erfahrungen der besten Führungskräfte der führenden Technologieunternehmen als Leitfaden an die Hand. Es zeigt Ihnen, wie Sie die Führungskraft werden, die Ihr Team und Ihr Unternehmen braucht, um nicht nur zu überleben, sondern zu gedeihen.

Leseprobe

Inhaltsverzeichnis

Cover

Titelblatt

Impressum

Widmung

Teil I: WAS WIR VON TOP-TECH-UNTERNEHMEN LERNEN KÖNNEN

1 Hinter jedem großen Unternehmen

Die Rolle der Technologie

Starkes Product Leadership

Product Teams mit Empowerment

Anmerkungen

2 Die Rolle der Technologie

Anmerkungen

3 Starkes Product Leadership

Die Aufgabe des Leaderships – Inspiration

Die Aufgabe des Managements – Execution

Notiz

4 Empowered Product Teams

5 Leadership in Aktion

6 Ein Leitfaden zu EMPOWERED

Für wen dieses Buch ist

Wie dieses Buch aufgebaut ist

Teil II: COACHING

7 Die geistige Haltung des Coachings

Job Nr. 1: Menschen bei ihrer Entwicklung fördern

Menschen Verantwortung zu übertragen, bringt die besten Ergebnisse

Hüten Sie sich vor Ihren eigenen Unsicherheiten

Fördern Sie verschiedene Sichtweisen

Schauen, wo es Möglichkeiten zum Lernen und Wachsen gibt

Verdienen Sie sich beständig das Vertrauen Ihres Teams

Haben Sie den Mut, Fehler zu korrigieren

8 Das Assessment

Mensch, Prozess, Produkt

Die Lücken-Analyse

Der Coaching-Plan

9 Der Coaching-Plan

Produktkenntnis

Prozesskenntnis und Methoden

Soziale Kompetenz und Verantwortung

Anmerkungen

10 Das Eins-zu-Eins

Schlüssel für das erfolgreiche 1:1

Anti-Vorbilder

Zusammenfassung

11 Written Narrative

Notiz

12 Strategischer Kontext

Company Mission

Company Scorecard

Company Objectives

Product Vision und Prinzipien

Team Topology

Product Strategy

13 Das Bewusstsein von Ownership

Anmerkungen

14 Zeit-Management

15 Denken

16 Team-Zusammenarbeit

Notiz

17 Zusammenarbeit mit Stakeholdern

18 Impostor-Syndrom

Notiz

19 Kundenzentrierung

Anmerkungen

20 Integrität

Verlässlichkeit

Im besten Interesse des Unternehmens

Verantwortlichkeit

21 Entscheidungen

Entscheidungs-Analyse richtigen Ausmaßes

Entscheidungsfindung auf kollektiver Basis

Meinungsverschiedenheiten lösen

Transparenz

Disagree and Commit

Notiz

22 Effiziente Besprechungen

Kommunikation

Entscheidungen

Problemlösung

Erfolgreiche Besprechungen organisieren

23 Ethik

Notiz

24 Glück

Sinnvolle Arbeit

Persönliche Beziehung

Persönliche Anerkennung

Einstellung zur Arbeit

Gute Führung vorleben

Karriereplanung

Notiz

25 Führungsprofil: Lisa Kavanaugh

Der Weg zum Leadership

Leadership in Aktion

Teil III: STELLENBESETZUNG

26 Kompetenz und Charakter

Kompetenz

Charakter

Anmerkungen

27 Recruiting

Notiz

28 Vorstellungsgespräche

Notiz

29 Einstellen von Personal

Notiz

30 Remote Worker

Artefakte

Vertrauen

Zeit

Anmerkungen

31 Onboarding

32 Bootcamp für neue Mitarbeiter

33 Performance Reviews

34 Kündigungen

35 Beförderungen

36 Führungsprofil: April Underwood

Leadership in Aktion

Teil IV: PRODUKTVISION UND PRINZIPIEN

37 Eine überzeugende Vision erschaffen

Kundenorientierung

Nordstern

Umfang und Zeitrahmen

Branchentrends zum Vorteil nutzen

38 Die Produktvision verbreiten

Die Produktvision bekanntmachen

Die Produktvision validieren

Produktvision als Instrument für die Rekrutierung

Produktvision als Missionierungs-Werkzeug

39 Produktprinzipien und -ethik

Notiz

40 Führungsprofil: Audrey Crane

Der Weg zum Leadership

Leadership in Aktion

Notiz

Teil V: TEAM TOPOLOGY

41 Optimierung für das Empowerment

Ownership

Autonomie

Anpassung

42 Team-Typen

Platform Teams

Experience Teams

43 Empowering Platform Teams

Shared Team Objectives

Platform-as-a-Product Objectives

Notiz

44 Empowering Experience Teams

Medienprodukte

E-Commerce-Produkte

Unternehmensprodukte

Marketplace Product

Customer-Enabling Product

45 Topologie und räumliche Nähe

Optimierung für das Product Team

Notiz

46 Topologie-Entwicklung

Eine Topologie entwickeln

Topologie-Warnsignale

Notiz

47 Führungsprofil: Debby Meredith

Der Weg zum Leadership

Mitarbeiterführung in Aktion

Teil VI: PRODUKTSTRATEGIE

48 Fokus

Anmerkungen

49 Erkenntnisse

Quantitative Erkenntnisse

Qualitative Erkenntnisse

Technische Erkenntnisse

Branchen-Erkenntnisse

Erkenntnisse weiterverbreiten

Notiz

50 Handeln

51 Management

52 Führungsprofil: Shan-Lyn Ma

Der Weg zum Leadership

Leadership in Aktion

Teil VII: TEAM OBJECTIVES

53 Empowerment

Probleme zum Lösen übertragen statt Features, die zu erstellen sind

Den strategischen Kontext mitteilen

54 Assignment

Zuweisung von Objectives an Product Teams

Ermittlung von Key Results

Ausrichtung

Das-Licht-am-Brennen-halten-Arbeit

Notiz

55 Ambition

56 Commitment

High Integrity Commitments

Ergebnisse

Nachverfolgen von High Integrity Commitments

57 Zusammenarbeit

Shared Team Objectives

Common Objectives

Notiz

58 Management

Das-Licht-am-Brennen-halten-Arbeit

Wöchentliche Verfolgung von Fortschritten

Auf Spur bleiben

Unseren Kollegen helfen

59 Haftung

Notiz

60 Objectives ins rechte Licht rücken

61 Führungsprofil: Christina Wodtke

Der Weg zum Leadership

Leadership in Aktion

Notiz

Teil VIII: FALLSTUDIE

62 Unternehmens-Hintergrund

Notiz

63 Company Objectives

Notiz

64 Produktvision und Leitlinien

65 Team-Topologie

Übersicht Team Topology

Anmerkungen

66 Produktstrategie

Fokus

Erkenntnisse

Handeln

Management

Anmerkungen

67 Product Team Objectives

Unternehmens-Dashboard

Anmerkungen

68 Geschäftsergebnisse

69 Die wichtigsten Punkte

70 Führungsprofil: Judy Gibbons

Der Weg zum Leadership

Leadership in Aktion

Teil IX: INNERBETRIEBLICHE ZUSAMMENARBEIT

71 Die Rolle von Produktleitern

Geschäftsergebnisse

Produktstrategie

Product Teams

72 Stakeholder-Management vs. Zusammenarbeit

73 Erkenntnisse und Lehren teilen

74 Das Licht am Brennen halten

75 Missionieren

76 Führungsprofil: Avid Larizadeh Duggan

Der Weg zum Leadership

Leadership in Aktion

Teil X: INSPIRIERT, EMPOWERED UND TRANSFORMIERT

77 Sinnvolle Transformation

78 Transformation in Aktion

Notiz

79 Transformiert

80 Das Allerwichtigste

81 Das Ziel

Letzte Gedanken

Danksagung

Über die Autoren

Mehr lernen

Stichwortverzeichnis

End User License Agreement

Orientierungspunkte

Cover

Titelblatt

Impressum

Widmung

Inhaltsverzeichnis

Fangen Sie an zu lesen

Danksagung

Über die Autoren

Stichwortverzeichnis

End User License Agreement

Seitenliste

3

4

5

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

31

33

35

36

37

39

40

41

42

43

44

45

46

47

48

49

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

67

68

69

70

71

72

73

75

76

77

79

80

81

82

83

84

85

86

87

89

90

91

93

94

95

96

97

98

99

100

101

103

104

105

106

107

109

110

111

112

113

114

115

116

117

119

120

121

123

124

125

127

128

129

130

131

133

134

135

137

138

139

141

142

143

144

145

146

147

148

149

151

152

153

155

156

157

159

160

161

162

163

164

165

166

167

169

170

171

173

174

175

176

177

178

179

181

182

183

185

186

187

188

189

190

191

192

193

194

195

197

198

199

200

201

202

203

204

205

207

208

209

211

212

213

215

216

217

219

220

221

222

223

224

225

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

243

244

245

246

247

248

249

251

252

253

255

256

257

258

259

261

262

263

264

265

266

267

268

269

271

272

273

274

275

276

277

278

279

281

282

283

284

285

286

287

288

289

290

291

293

294

295

297

298

299

301

302

303

304

305

307

308

309

310

311

312

313

315

316

317

318

319

320

321

323

324

325

326

327

328

329

330

331

333

334

335

337

338

339

340

341

342

343

344

345

346

347

348

349

351

352

353

354

355

356

357

358

359

360

361

362

363

365

366

367

369

370

371

372

373

374

375

376

377

Das englische Original erschien 2021 unter dem Titel Empowered. Ordinary People, Extraordinary Products bei John Wiley & Sons, Inc., Hoboken, New Jersey

Copyright © 2021 by John Wiley & Sons, Inc.

All rights reserved. This translation published under license with the original publisher John Wiley & Sons, Inc.

Alle Bücher von WILEY-VCH werden sorgfältig erarbeitet. Dennoch übernehmen Autoren, Herausgeber und Verlag in keinem Fall, einschließlich des vorliegenden Werkes, für die Richtigkeit von Angaben, Hinweisen und Ratschlägen sowie für eventuelle Druckfehler irgendeine Haftung

© 2022 Wiley-VCH GmbH, Boschstraße 12, 69469 Weinheim, Germany

Alle Rechte, insbesondere die der Übersetzung in andere Sprachen, vorbehalten. Kein Teil dieses Buches darf ohne schriftliche Genehmigung des Verlages in irgendeiner Form – durch Photokopie, Mikroverfilmung oder irgendein anderes Verfahren – reproduziert oder in eine von Maschinen, insbesondere von Datenverarbeitungsmaschinen, verwendbare Sprache übertragen oder übersetzt werden. Die Wiedergabe von Warenbezeichnungen, Handelsnamen oder sonstigen Kennzeichen in diesem Buch berechtigt nicht zu der Annahme, dass diese von jedermann frei benutzt werden dürfen. Vielmehr kann es sich auch dann um eingetragene Warenzeichen oder sonstige gesetzlich geschützte Kennzeichen handeln, wenn sie nicht eigens als solche markiert sind.

Bibliografische Information der Deutschen NationalbibliothekDie Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über <http://dnb.d-nb.de> abrufbar.

Print ISBN: 978-3-527-51087-0ePub ISBN: 978-3-527-83610-9

Umschlaggestaltung: Susan Bauer, Mannheim (Übernommen von Wiley & Sons, USA)

Dieses Buch ist Bill Campbell (1940-2016) gewidmet, bekannt und hochverehrt als der Coach vom Silicon Valley. Ich habe Bill zwar im Lauf der Jahre ein paar Mal getroffen, aber ich hatte leider nicht das Glück, von ihm selbst gecoacht zu werden. Doch ich kann mich glücklich schätzen, dass einige Führungspersönlichkeiten, von denen ich gemanagt und gecoacht worden bin, ihrerseits von Bill gecoacht wurden. So erkenne ich immer mehr, wie viele der wichtigen Lektionen, die ich über Leadership, Empowerment, Teams und starke Unternehmen gelernt habe, auf Bill zurückgehen.

Teil IWAS WIR VON TOP-TECH-UNTERNEHMEN LERNEN KÖNNEN

Mein erstes Buch, INSPIRED, beschäftigte sich mit der Frage, wie starke Produkt-Teams der besten Technologie-Unternehmen die modernen Methoden der Product Discovery (Produktentdeckung) nutzen, um schwierige Probleme zu lösen, und zwar so, dass die Kunden es lieben und es gleichzeitig für das Business funktioniert.

INSPIRED führte mich und meine SVPG-Partner in viele weitere Unternehmen, weit über das Silicon Valley hinaus.

Das Auffälligste, was wir dabei in Erfahrung brachten, war, dass in sehr vielen Unternehmen – sogar in solchen, die sich in wirklich technologiegetriebenen Produkten und Dienstleistungen versuchten – es den Produkt-Teams allzu oft nicht gestattet war, so zu arbeiten, wie sie es hätten tun müssen, um wirklich erfolgreich zu sein.

Wir erkannten, dass es nicht nur die Arbeitsmethoden sind, die starke Produkt-Teams nutzen, um erfolgreiche Produkte zu entdecken und zu entwickeln, sondern dass die Unterschiede, wie großartige Tech-Unternehmen im Gegensatz zum Rest arbeiten, viel tiefgreifender sind.

Was wir in diesen restlichen Unternehmen fanden, war alles andere als schön.

Die Rolle der Technologie

Was die Technologie betrifft, herrscht in vielen Unternehmen noch immer die alte IT-Denkart vor. Das heißt, Technologie wird mehr als notwendiger Kostenfaktor betrachtet und weniger als die Wegbereiterin für das Kerngeschäft, was sie notwendigerweise ist. Die Menschen, die in den Technologie-Teams arbeiten, sind buchstäblich dort, um »dem Betrieb zu dienen«, und die Technologie-Manager und -Leiter sind dort, um dieses »Dienen« zu erleichtern. Oder die Technologie wird in einen »digitalen« Geschäftsbereich abgeschoben. Die Technologie-Teams sind abgetrennt von den wirklichen Kunden – tatsächlich werden sie darin bestärkt, die Stakeholder als ihre Kunden zu betrachten.

Coaching

Es gibt wenig bis kein aktives Coaching der Mitarbeiter in Technologie-Teams. Und selbst wenn die Manager ihre Mitarbeiter coachen wollten, besitzen sie häufig nicht die Erfahrung dazu. Und so setzen sich die Probleme endlos fort.

Stellenbesetzung

Die meisten dieser Unternehmen erkennen, dass sie nicht die Mitarbeiter haben, die sie eigentlich bräuchten, aber sie haben sehr irrige Ideen, wie sie das korrigieren könnten und worauf sie bei Mitarbeitern für den Produktbereich achten sollten. Und auch hier setzen sich die Probleme endlos fort.

Produktvision

Diese Unternehmen haben nur selten eine inspirierende, überzeugende Produktvision. Sie haben vielleicht einmal eine gehabt – in der Frühphase des Unternehmens –, doch nachdem die Unternehmensgründer gingen, verblasste die Vision. Die Mitarbeiter in den Technologie-Teams fühlen sich, als würden sie nur in einer Feature Factory arbeiten.

Team-Topologie

Die Technologie-Mitarbeiter werden in Teams eingeteilt, in denen sie das Gefühl haben, für nichts wirklich Wichtiges verantwortlich, bei all ihrem Tun von den Eingriffen anderer Teams abhängig und nur kleine Rädchen im riesigen Getriebe zu sein.

Produktstrategie

Es wäre nicht fair zu sagen, dass die meisten dieser Unternehmen eine schwache Produktstrategie haben, denn in Wahrheit haben die meisten überhaupt keine Strategie. Sie versuchen nur, so viele Stakeholder wie möglich zufriedenzustellen mit dem Personal, der Zeit und den Fähigkeiten, die sie haben.

Team-Zielvorgaben

Die meisten dieser Unternehmen haben gehört, dass Google und andere die OKR-Methode nutzen (Objectives and Key Results; Zielsystem, um Ziele zu formulieren, zu kommunizieren und zu messen), um ihre Arbeit zu managen, und die Chefs haben ein Video geschaut oder ein Buch darüber gelesen und finden, das klinge doch ganz einfach. Also wird die Methode übernommen – und auf die bestehenden Product Roadmaps und die Firmenkultur draufgesattelt –, und in jedem Quartal gibt es dann eine Planungsübung, die einige Wochen in Anspruch nimmt und dann für den Rest des Quartals weitgehend ignoriert wird. Die meisten Leute in den Teams sagen, dass sie wenig bis keinen Nutzen aus dieser Methode ziehen.

Beziehung zum Unternehmen

Die Beziehungen zwischen den Technologie-Teams und dem Rest des Unternehmens sind nicht gut. Die Stakeholder und Führungskräfte haben wenig oder kein Vertrauen zu den Technologie-Teams. Und die Mitarbeiter in den Technologie-Teams fühlen sich wie wenig wertgeschätzte, dienstbare Geister, wie bloße Söldner im Dienst des Betriebs.

Empowered Teams

Am schlimmsten ist, dass die Teams nicht »empowered« sind, das heißt, ihnen wird nicht zu der Handlungsfähigkeit verholfen, Probleme auf eine Art und Weise zu lösen, die die Kunden lieben und die gleichzeitig für den Betrieb funktionieren. Und ohne diese Befähigung zur Eigenverantwortung können die Teams auch nicht für Ergebnisse zur Rechenschaft gezogen werden.1

Der Produktmanager ist in Wahrheit ein Projektmanager, er führt die angehäuften Posten durch den Prozess. Die Designer und Entwickler (Engineers) sind nur da, um die Features auf der Roadmap zu entwickeln und zu programmieren.

Die Motivation ist gering, das Gefühl von Anteilhabe minimal und Innovation selten.

Es ist unschwer zu erkennen, warum so viele dieser Unternehmen vor einer Zerreißprobe stehen. In starken Unternehmen dagegen wird der Produktbereich völlig anders gehandhabt.2

Besonders schockierend ist für mich, dass es wirklich kein Geheimnis ist, wie die besten Unternehmen funktionieren und wie sie finanziell erfolgreich sind. Was die Frage aufwirft: Warum tun sich so viele Unternehmen mit einer Transformation derart schwer?

Das Problem ist meiner Erfahrung nach nicht, dass diese Unternehmen sich nicht transformieren wollen, sondern dass Transformation schwierig ist und dass sie einfach nicht wissen, wie es geht. Oder vielleicht sogar, dass sie nicht wissen, was es wirklich bedeutet, sich zu transformieren.

Was diese Unternehmen brauchen, ist der Übergang bzw. die Entwicklung hin zu Team-Empowerment, zu Teams mit Eigenverantwortung.

Nun, möglicherweise ist Ihnen der Begriff neu, und Sie werden vielleicht nicht einmal realisiert haben, dass es verschiedene Arten von Technologie-Teams gibt.

Aber wenn das, was ich oben beschrieben habe, Ihnen in Bezug auf Ihr Unternehmen bekannt vorkommt, dann machen Sie sich auf einige harte Wahrheiten gefasst.

Erstens: Bei Ihrer Arbeitsweise ist Ihre Chance, bedeutende Geschäftsergebnisse zu erzielen, sehr gering, ganz zu schweigen von tatsächlicher Innovation.

Zweitens: Ihre Kunden sind große, reife Zielobjekte für einen Konkurrenten, der anders arbeitet als Sie (z. B. Amazon) und weiß, wie man Produkte zur Verfügung stellt, die von den Kunden geliebt werden und zugleich für das eigene Business funktionieren.

Drittens: Sie verschwenden in hohem Maße die Talente und Fähigkeiten der Menschen, die Sie angestellt haben, und Ihre besten Mitarbeiter – diejenigen, die Sie dringend brauchen, um zu überleben und zu wachsen – werden wahrscheinlich gehen.

Zuletzt: Wenn Sie denken, Sie hätten mit dem Übergang zu Agilität bereits eine Art digitale Transformation geschafft, so muss ich Ihnen leider sagen, Sie haben nicht einmal damit angefangen.

Ich hoffe, Sie lesen dieses Buch, weil Sie überzeugt sind, dass es einen besseren Weg gibt.

Denn ja: Es gibt ihn.

Anmerkungen

1

   Hinweis zur Übersetzung: Wenn im folgenden Buch über empowered Teams geschrieben wird, dann sind im Sinne der hier gelieferten Erläuterung Teams mit der Befähigung zur Eigenverantwortung gemeint. Man könnte sie auch einfacher als »Teams mit Eigenverantwortung« bezeichnen, eine Formulierung, die sich auch im Text dieses Buches findet.

2

   Um es ganz klar zu sagen, wir haben außergewöhnlich starke Unternehmen auch weit über Silicon Valley hinaus gefunden, u.a. in Shanghai, Melbourne, Tel Aviv, London, Berlin und Bangalore, genau wie wir sehr schwache Unternehmen im Herzen von San Francisco gefunden haben. Es ist der

Unterschied

zwischen den besten und dem Rest, auf den wir uns in diesem Buch fokussieren.

1Hinter jedem großen Unternehmen

In diesem Buch möchte ich die Unterschiede beleuchten, wie die besten Unternehmen Technologie-Produkte erzeugen und wie die meisten Unternehmen es tun.

Diese Unterschiede sind sowohl fundamental als auch bemerkenswert.

Die Unterschiede beinhalten sicherlich das, woran viele Menschen denken, wenn sie »Product Culture« (Produktkultur) hören, aber starke Technologie-Unternehmen haben oft sehr voneinander abweichende Produktkulturen, und so geht es ganz klar darüber hinaus.

Man denke zum Beispiel an Amazon, Google, Apple und Netflix. Alle vier sind sehr starke Tech-Unternehmen, die sich seit vielen Jahren kontinuierlich erneuern – und doch hat jedes Unternehmen eine ganz eigene Kultur.

So glaube ich zwar nach wie vor, dass die Kultur sehr wichtig ist. Aber die besten Tech-Unternehmen haben etwas, das noch fundamentaler ist.

Und zwar ist es ihr Verständis davon, welche Rolle die Technologie spielt, und davon, welchem Ziel die Mitarbeiter folgen, die diese Technologie erschaffen, und wie sie von diesen Menschen erwarten, bei der Lösung von Problemen zusammenzuarbeiten.

Ich glaube nicht, dass es ein Zufall ist, dass diese vier Unternehmen – trotz ihrer unterschiedlichen Kulturen – die wichtigsten Elemente gemeinsam haben.

Ich werde in diesem Buch versuchen, diejenigen Teile der Unternehmenskultur, die in erster Linie die Persönlichkeit der Unternehmensgründer widerspiegeln, von denjenigen zu trennen, die essenziell für beständige Innovation sind.

Ich möchte gern die wichtigen Lektionen vermitteln, die ich darüber gelernt habe, was die Besten vom Rest unterscheidet.

Ein roter Faden, der sich durch viele der besten Tech-Unternehmen zieht, ist überraschenderweise der legendäre Coach Bill Campbell. Bill coachte die Gründer von Apple, Amazon und Google und einige andere während ihrer prägenden Jahre.

Um ein Gefühl für Bills Anschauungen und Werte zu bekommen, hier eines meiner Lieblingszitate von ihm über die Rolle der Führung in einem starken Unternehmen:

Bei Führung bzw. Leadership geht es darum, zu erkennen, dass etwas Großes in jedem steckt, und dein Job ist es, eine Umgebung zu schaffen, in der sich diese Größe entwickeln kann.

Dieses Buch widmet sich ganz der Frage, was eine solche Umgebung ausmacht, und ich möchte Sie ermutigen, sich diese wichtigen Methoden und Verhaltensweisen anzueignen.

Ich möchte noch hinzufügen, dass ich nicht behaupte, dass diese erfolgreichen Tech-Unternehmen ausschließlich Vorzeige-Unternehmen sind. Alle wurden zu Recht wegen einiger ihrer Strategien und Geschäftspraktiken kritisiert.1

Aber was die Fähigkeit zu permanenter Innovation angeht, haben alle vier Unternehmen ihre Fähigkeiten unter Beweis gestellt, und ich glaube, dass sich viel von ihnen lernen lässt.

Im Wesentlichen sehe ich drei bedeutende Unterschiede zwischen den stärksten Produktherstellern und dem Rest:

Der erste besteht darin, wie diese Unternehmen die Rolle der Technologie bewerten.

Der zweite Unterschied ist die Rolle, die ihre Product Leader spielen.

Der dritte Unterschied liegt darin, wie die Unternehmen die Product Teams verstehen – die Product Manager, die Product Designer und Entwickler.

Sehen wir uns jeden dieser Punkte einmal genauer an.

Die Rolle der Technologie

Im Vergleich zum Großteil der Unternehmen haben starke bzw. erfolgreiche Unternehmen einen fundamental anderen Blick auf den Sinn und Zweck von Technologie.

Die große Mehrheit der Unternehmen sieht Technologie als notwendiges Übel. Sie wissen zwar, dass sie wichtig ist, aber sie empfinden sie eher als einen betrieblichen Kostenfaktor. Wenn sie dieses Thema outsourcen können, umso besser. Sie sehen sich selbst nicht im Tech-Business, sondern im Versicherungsgeschäft oder im Bankwesen oder im Transportwesen oder was auch immer. Sie brauchen Technologie, um zu funktionieren, das heißt, um den Betrieb aufrecht zu erhalten – aber im Wesentlichen hat Technologie nur eine unterstützende Funktion für das eigentliche Geschäft.

Deshalb besteht in den meisten Unternehmen die Aufgabe der Technologie-Teams darin, dem Business zu dienen. Das wird dort oft wortwörtlich so gesagt. Aber selbst wenn es nicht so deutlich ausgesprochen wird, ist es so, dass die Unternehmensbereiche bestimmen, was die Produkt-Teams tatsächlich entwickeln.

Im Gegensatz dazu ist in erfolgreichen Unternehmen die Technologie kein Kostenfaktor, sie selbst ist das Business. Technologie macht die Produkte und Dienstleistungen, die wir unseren Kunden anbieten, erst möglich und leistungsfähig. Es ist die Technologie, die es uns erlaubt, Probleme für unsere Kunden auf eine ganze andere Art und Weise zu lösen.

Ob das Produkt oder die Dienstleistung eine Versicherungspolice ist, ein Bankkonto oder eine Paketzustellung über Nacht: Im Kern geht es um ein Produkt, das Technologie als Enabler nutzt.

Entsprechend sehen starke Unternehmen es als die Aufgabe ihrer Produkt-Teams an, den Kunden zu dienen, indem sie Produkte schaffen, die die Kunden lieben werden – und die auf diese Weise auch dem Geschäft dienlich sind.

Das ist ein gravierender Unterschied, der sich beinahe auf alles im Unternehmen und wie es arbeitet auswirkt und zu einer viel höheren Motivation und Arbeitsmoral führt. Und der vor allem zu einem viel höheren Grad an Innovation und Wertschöpfung für die Kunden und das Business führt.

Starkes Product Leadership

In den meisten Technologieunternehmen gibt es keine echte Führung der Produkt-Teams.

Stattdessen sind die Teamleiter hauptsächlich für das Staffing (die Stellenbesetzung) des internen (oder im schlimmsten Fall outgesourcten) Produkt-Teams und für funktionierende Abläufe verantwortlich.

In den meisten Unternehmen gibt es keine Produktstrategie. Und damit meine ich nicht, dass es eine schlechte Produktstrategie gäbe – ich meine wortwörtlich, dass es KEINE Produktstrategie gibt. Die Feature Teams sind einfach da, »um dem Business zu dienen«.

Es gibt sicherlich Gründe dafür, was angefordert oder auf die Roadmap gesetzt wird – aber es gibt kaum eine wirkliche Produktstrategie, geschweige denn die Skills oder die nötigen Daten, um eine zu entwerfen.

Das führt dazu, dass die Stakeholder den Produkt-Teams lange Listen von priorisierten Features und Produkten übergeben, die sie in diesem Quartal oder Geschäftsjahr umsetzen müssen. Die sogenannte »Produktstrategie« ist also einfach, zu versuchen, so viele dieser Zielvorgaben wie möglich zu erfüllen.

Als Technologie-Unternehmen in den letzten zehn bis zwanzig Jahren zu agilen Methoden übergingen, stellten viele Manager und Führungskräfte infrage, ob sie selbst überhaupt noch gebraucht werden, da von den Team-Mitgliedern erwartet wurde, eine viel aktivere Rolle im Arbeitsprozess einzunehmen.

Es mag widersprüchlich klingen, doch der Übergang zu wirklich bevollmächtigten Teams erfordert zwar, sich vom alten Führungsverständnis von »command and control« abzuwenden – doch es bedeutet nicht, dass weniger Führungskräfte und Manager gebraucht werden. Es bedeutet, dass bessere Führungskräfte und Manager gebraucht werden.

Es ist tatsächlich leichter für einen Manager, weiterhin im alten Stil von command and control zu managen (oder sogar zu mikromanagen). Es ist leicht, einem Team eine To-do-Liste oder eine Feature List zu geben und ihm zu sagen, dass es einfach diese Liste so schnell wie möglich abarbeiten soll.

Nun mag dieser Command-and-Control-Stil für den Manager einfacher sein – aber er bringt lediglich Teams hervor, die Dienst nach Vorschrift tun, ohne eine Spur von sinnenhaftem Empowerment.

Dagegen gehören die Produktleiter in starken Unternehmen zu den einflussreichsten Führungskräften überhaupt.

Sie sind dafür verantwortlich, die Product Teams personell aufzustellen und zu coachen; sie sind für die Produktstrategie verantwortlich und dafür, die Strategie in die Praxis umzusetzen; und sie sind dafür verantwortlich, ergebnisorientiert zu führen.

Empowered Product Teams brauchen fähige Manager, Produkt-Designer und Entwickler (Engineers), und es ist die Verantwortung der Führungskräfte und Manager, diese Menschen anzuwerben, einzustellen und zu coachen.

Einer der wichtigsten Beiträge der Produktleitung ist darüber hinaus eine zielgerichtete und überzeugende Produktstrategie, die auf quantitativen und qualitativen Erkenntnissen beruht.

Product Teams mit Empowerment

In den meisten Unternehmen sind die Technologie-Teams keine Teams mit Eigenverantwortung, also empowered Teams, sondern schlicht »Feature Teams«.

Feature Teams wirken oberflächlich betrachtet wie Product Teams. Sie sind funktionsübergreifend, mit einem Product Manager, einem Product Designer und einigen Engineers. Der Unterschied besteht darin, dass sie zwar für die Implementierung von Features und Projekten, also für Output, verantwortlich sind – aber da sie keine echte Entscheidungshoheit haben, können sie auch nicht für die Ergebnisse verantwortlich gemacht werden.

Feature Teams verorten und sortieren die Features zunächst auf der Roadmap, dann führen sie vielleicht einige Usability-Tests durch, dann machen sie sich ans Erarbeiten der Features, ans Testen und schließlich an das Deployment (Delivery).

Diese Feature Teams würden von sich behaupten, auch Product Discovery zu machen – aber in Wirklichkeit ist das nur selten der Fall. Denn ihnen wurde schon vorher gesagt, wie die Lösung aussehen soll. Sie wurden nicht dazu ermächtigt, eine eigene Lösung zu kreieren. Ihr Job ist lediglich das Design und das Coding.

In diesen Feature Teams gibt es normalerweise eine Person mit dem Titel des Product Managers, aber was diese Person macht, ist hauptsächlich Projektmanagement. Sie stellt sicher, dass die Features konzipiert und geliefert werden. Das ist nötig – aber das ist kein Produktmanagement.

Die Feature Teams erhalten Roadmaps mit Features und Projekten (oder sie müssen die Roadmaps ganz und gar selbst erstellen). Deshalb liegt der Fokus des Teams auf Delivery – auf der Lieferung dieser Features. Die Features selbst sind also der Output. Wenn dieser Output nun keinen Impact auf die Geschäftsergebnisse hat, wen könnte man dafür verantwortlich machen?

Im Gegensatz dazu erhalten die Teams in starken Tech-Unternehmen keine fertigen Feature-Listen. Sie bekommen stattdessen Probleme übertragen, für die sie Lösungen finden müssen. Und vor allem bekommen sie die Verantwortung dafür, diese Probleme auf die bestmögliche Art und Weise, die sie sich ausdenken können, zu lösen. Sie sind »empowered«.

In dem Product-Team-Modell mit Empowerment haben Product Manager eine klare Verantwortlichkeit, und zwar, sicherzustellen, dass die Lösungen nützlich sind (»unsere Kunden werden das Produkt kaufen und/oder es benutzen«) und dass sie existenzfähig sind (»sie entsprechen den Anforderungen unseres Geschäfts«). Gemeinsam mit einem Product Designer, der dafür verantwortlich ist, dass die Lösung usable, also bedienbar ist, und einem Technik-Lead, in dessen Verantwortung liegt, dass sie feasible, also umsetzbar ist, ist das Team in der Lage, bei der Bewältigung dieses gesamten Spektrums an Risiken zusammenzuarbeiten (Value/Wert, Viability/Wirtschaftlichkeit, Usability/Bedienbarkeit und Feasibility/Umsetzbarkeit). Gemeinsam haben sie die Verantwortung für das Problem und sind für ihre Ergebnisse verantwortlich und rechenschaftspflichtig.2

Fassen wir also zusammen, was Feature Teams von empowered Product Teams unterscheidet:

Feature Teams sind funktionsübergreifend (ein Product Manager, der hauptsächlich Projektmanagement macht, ein Produktdesigner plus einige Entwickler) und werden damit beauftragt, Features zu erstellen und Projekte durchzuführen, statt Probleme zu lösen, und somit geht es ihnen ganz und gar um Output, um Produktion, und nicht um Geschäftsergebnisse.

Product Teams mit Empowerment sind ebenfalls funktionsübergreifend (ein Product Manager, ein Produktdesigner und Entwickler), doch im Gegensatz zu Feature Teams wird von ihnen erwartet, dass sie Probleme lösen, und sie sind außerdem mit der entsprechenden Entscheidungskompetenz ausgestattet, um Lösungen zu finden, die funktionieren – gemessen am Ergebnis. Für deren Erfolg werden sie zur Rechenschaft gezogen.3

Product Discovery

Wenn Sie INSPIRED noch nicht gelesen haben, dann fragen Sie sich vielleicht: Was ist so falsch daran, wenn Geschäftsinhaber und Stakeholder entscheiden, was auf die Roadmap kommt, und somit auch, was die Engineers (Entwickler) bauen sollten?

Dies gilt als das erste und wichtigste Prinzip der Product Discovery: Unsere Kunden und unsere Stakeholder sind nicht in der Lage dazu, uns zu sagen, was gebaut wird.

Und zwar nicht, weil unsere Kunden oder Stakeholder nicht klug oder sachkundig genug wären. Sondern aus zwei anderen Gründen:

Erstens wissen Kunden und Stakeholder nicht, was zum jetzigen Zeitpunkt gerade technisch möglich ist – sie sind keine Technologie-Experten, also können sie auch nicht wissen, wie das jeweilige Problem am besten gelöst werden kann oder ob es überhaupt gelöst werden kann. Oft lösen echte Innovationen Probleme auf eine Art und Weise, die Kunden oder Stakeholder nie für möglich gehalten hätten.

Zweitens ist bei Technologieprodukten sehr schwer vorherzusagen, welche Lösungen funktionieren. Es gibt viele Gründe, warum Produktideen nicht zu den erhofften Ergebnissen führen. Allzu oft sind wir begeistert von einer Idee, aber unsere Kunden sind es nicht – also werden sie das Produkt entgegen unserer Erwartung auch nicht kaufen. Oder die Idee bringt Probleme hinsichtlich Datenschutz oder Sicherheit mit sich. Oder die Verwirklichung der Idee würde viel länger brauchen, als irgendjemand erwartet hätte.

Product Teams mit Empowerment verstehen diese inhärenten Herausforderungen, und bei der Product Discovery geht es um die Entdeckung einer Lösung, die unsere Kunden lieben und die gleichzeitig für unser Business funktioniert.

Wir bezeichnen dies als »Product Discovery«, um deutlich zu machen, dass wir vieles nicht vorher wissen können, und um zu unterstreichen, dass unsere Aufgabe darin besteht, eine Lösung zu entdecken, die valuable (nutzbringend), usable (bedienbar), feasible (umsetzbar) und viable (existenzfähig) ist.

Anmerkungen

1

   Eine unverblümte Kritik der Politik dieser Unternehmen bieten die Schriften von Professor Scott Galloway (

www.profgalloway.com

).

2

   Natürlich tragen der Designer und der technische Leiter viel mehr bei, als nur die Nutzerfreundlichkeit bzw. technische Durchführbarkeit sicherzustellen; worauf ich mich hier beziehe, ist, wer jeweils verantwortlich und rechenschaftspflichtig für das jeweilige Risiko ist.

3

   Es gibt tatsächlich eine dritte Art von Technologie-Team, die als Delivery Team (oder »Scrum Team« bzw. »DEV-Team«) bezeichnet wird. Ein Delivery Team gibt noch nicht einmal vor, ein echtes Product Team zu sein. Es ist nicht funktionsübergreifend, und es besitzt keine Eigenverantwortung. Es gibt einen Product Owner (verantwortlich für die Verwaltung des Product Backlogs) und eine Reihe von Entwicklern. Es geht rein um den Output (Code and Ship, also das Programmieren und Ausliefern von Software-Projekten). Wenn Sie in einem Prozess wie SAFe involviert sind, dann betrifft Sie dies leider, und ehrlicherweise habe ich keine Ahnung, warum Sie dieses Buch lesen wollen würden, denn was ich hier beschreibe, ist das genaue Gegenteil davon, sowohl was die Unternehmensphilosophie als auch was die unternehmerische Praxis angeht.

2Die Rolle der Technologie

Ich verspreche, dass dieses Buch sehr praxisnah ist, und Sie werden alles, was hier behandelt wird, direkt anwenden können. Aber in diesem einen Kapitel müssen wir ein kleines bisschen philosophisch werden.

Es ist leicht, die Unterschiede zwischen Feature Teams und Product Teams mit Empowerment zu erkennen.

Es ist leicht zu erkennen, ob Unternehmen es als die Aufgabe von Teams verstehen, dem Business zu dienen, oder ob die Aufgabe ist, dem Kunden zu dienen und damit auch dem Business.

Es ist leicht zu erkennen, ob ein Unternehmen nur versucht, so viele Stakeholder wie möglich zufriedenzustellen, oder ob ein Unternehmen eine klare und bewusste Produktstrategie hat.

Diese Unterschiede mögen leicht erkennbar sein, doch erklärt das nicht, warum diese Unterschiede existieren.

Wenn wir die Lücke zwischen den besten Unternehmen und dem Rest schließen wollen, müssen wir ein wenig Ursachenforschung betreiben.

Ungefähr vor einem Jahrzehnt veröffentlichte Marc Andreessen einen Aufsatz, den ich für einen der wichtigsten unserer Zeit halte: »Why Software is eating the World«.1 Er beschrieb darin, warum er glaubte, dass Technologie dabei sei, große Disruptionen in nahezu jeder Branche zu verursachen. Er brachte genau das zum Ausdruck, was ich bei meiner eigenen Arbeit beobachten konnte – in erster Linie bei den Disruptoren, aber gelegentlich auch bei jenen, die von Disruption bedroht waren.

Zehn Jahre später ist klar, dass er bemerkenswert vorausschauend war.

Trotzdem scheinen die meisten Unternehmen diese Warnungen noch nicht wirklich begriffen zu haben.

Ja, sie alle geben inzwischen Geld für Software aus.

Ja, sie haben sich (zumeist) hin zu agilen Methoden bewegt.

Aber die meisten haben sich nicht auf irgendeine sinnvolle Art und Weise transformiert, und insbesondere sehen die meisten von ihnen die Technologie immer noch nicht als den Business Enabler, der sie ist.

Beispiele dafür finden sich leider überall.

Eines der deutlichsten und ungeheuerlichsten Beispiele aus jüngerer Zeit ist sicherlich die absolute Unfähigkeit der Unternehmensleitung von Boeing im Umgang mit der Software, welche die schockierende Krise der Flugzeuge 737 MAX auslöste.2

Der fundamentale Fehler von Boeing war, diese Software lediglich als notwendigen Kostenfaktor zu begreifen statt als die Kernkompetenz, die es dem Unternehmen erlaubt, die sichersten, benzinsparendsten und rentabelsten Flugzeuge zu bauen, die es gibt.

Statt ein Product Team mit Empowerment zusammenzustellen – das fortlaufend daran gearbeitet hätte, die sicherste, benzinsparendste, überlebenswichtige Steuerungssoftware bereitzustellen –, beschloss die Unternehmensführung bei Boeing, ausgerechnet diese Technologie auszulagern. Man dachte, durch Outsourcen könne man vielleicht ein paar Dollar sparen.

Das betrifft nicht nur die Luftfahrtbranche. Die Automobilbranche hat unter dieser Denkweise jahrzehntelang gelitten3, bis Tesla daherkam und bewies, was eigentlich alles möglich ist, wenn die Fahrzeugentwicklung Technologie wirklich ins Zentrum stellt und nicht nur als notwendigen Kostenfaktor behandelt. Indem die Technologie im Tesla weit über Navigation und Unterhaltungssysteme hinausgeht und die technologischen Möglichkeiten zum Beispiel mit Over-the-Air-Updates (Softwareaktualisierung über eine Funkschnittstelle) voll ausnutzt, verbessert ein Tesla sich im Laufe der Zeit eher, als dass er an Wert verliert. Es lohnt sich, darüber einen Moment lang nachzudenken.

Pixar hat der Filmbranche gezeigt, was eigentlich alles möglich ist, wenn die Produktion von animierten Spielfilmen Technologie in den Mittelpunkt stellt, anstatt sie nur als notwendigen Kostenfaktor zu sehen. Pixar verwendet Technologie auf eine Art und Weise, die weit über das traditionelle Filmemachen hinausgeht, und die Technologie-Teams werden genauso wertgeschätzt wie die Kreativ-Teams.

Wie Sie vielleicht wissen, gehört Pixar inzwischen zu Disney – und es ist interessant zu sehen, wie sich Disney die Technologie zu eigen gemacht hat, um viele der bestehenden Geschäftsbereiche neu zu denken. Das reicht von den traditionellen Themenparks bis hin zum neuesten Disney+ Video-Streaming-Dienst.

Die gleiche Entwicklung zeigt sich in der Versicherungsbranche, im Bankenwesen, in der Gesundheitsfürsorge, in der Telekommunikationsbranche, in der Erziehung, in der Landwirtschaft, im Transportwesen und in der Rüstungsindustrie. Ich könnte die Liste noch weiter fortführen.

Wenn ich ein Abendessen mit einem der CEO eines der Unternehmen habe, die das nicht verstanden haben, erzählen sie mir, dass sie kein Technologie-Unternehmen seien – sie seien ein Versicherungsunternehmen oder ein Unternehmen im Gesundheitswesen oder ein agrarwirtschaftliches Unternehmen. Ich sage dann: »Und ich erzähle Ihnen mal, was ich tun würde, wenn ich ein Produktleiter bei Amazon oder Apple wäre und wir beschlossen hätten, in Ihren Markt einzudringen, weil wir glauben, dass er groß ist und es eine Marktlücke gibt und dass Technologien verfügbar sind, die deutlich bessere Lösungen für Ihre Kunden ermöglichen.«

Nachdem ich erklärt habe, wie wir unsere Teams rund um die Technologien aufstellen würden, um eine Optimierung und wirkliche Innovation hervorzubringen, erkläre ich ihm auch, dass wir sicher sind, dass er in diesem Fall nicht konkurrenzfähig wäre, weil sein Unternehmen zu sehr damit beschäftigt ist, das bisherige Geschäftsmodell zu beschützen.

Nicht dass diese CEOs das, was Unternehmen wie Amazon und Netflix und andere getan haben, nicht bewundern würden – das tun sie in der Regel. Aber sie verstehen nicht, dass diese Lektionen sie selbst betreffen. Sie verstehen nicht, wovor Marc Andreessen sie zu warnen versuchte.

Natürlich gibt es viele mögliche Gründe, warum die Chefs dieser Unternehmen es nur langsam verstehen. Manchmal haben sie so lange in der alten Arbeitswelt gearbeitet, dass sie mehr Zeit brauchen, um die Veränderungen zu verstehen. Manchmal glaube ich auch, sie haben Angst vor der Technologie. Manchmal scheinen sie sich einfach gegen Veränderungen zu wehren. Aber letztlich sind das alles nur Entschuldigungen. Der Vorstand oder Aufsichtsrat sollte sicherstellen, dass ein CEO fähig ist, das Unternehmen erfolgreich zu führen.

Die Ironie darin ist, dass diese Unternehmen fast immer weitaus mehr für Technologie ausgeben, als sie es müssten. Tatsächlich habe ich nie mehr in die Technologie verschwendete Investitionen gesehen als bei jenen Unternehmen, die die eigentliche Rolle der Technologie nicht verstehen.

Ich erkläre ihnen dann, dass sie, statt Heerscharen von Entwicklern mit Söldnermentalität mit langen Feature-Listen der Stakeholder auszustatten, die nicht zu den gewünschten Geschäftsergebnissen führen werden, besser eine signifikant kleinere Anzahl von Mitarbeitern haben sollten, die, wenn es die richtigen Mitarbeiter sind, eine viel höhere Rendite erwirtschaften würden – Mitarbeiter, die die Aufgabe haben, Probleme des Unternehmens oder der Kunden zu lösen, und die für die Ergebnisse verantwortlich sind.

Um heutzutage zu einem der besten Unternehmen zu werden, braucht es Führungskräfte, die die fundamentale Rolle der Technologie verstehen.

Der Technology Leader

Wie ein Unternehmen die Rolle von Technologie bewertet, erkennt man gewöhnlich sehr gut daran, ob die produktverantwortlichen Entwickler einem CIO berichten (Chief Information Officer) bzw. einem IT-Leiter oder ob sie einem CTO berichten (Chief Technology Officer).

Dieser Sachverhalt scheint unwesentlich, ist aber meiner Erfahrung nach ein viel bedeutenderes Hindernis für Transformation, als die meisten Unternehmen erkennen.

Unter dem großen Vorbehalt, dass jeder einzelne CIO eine einzigartige Persönlichkeit ist und ich keinen Anspruch auf Allgemeingültigkeit erhebe, denke ich doch, dass dieser Punkt ernsthaft und ehrlich in Betracht gezogen werden sollte. Und es ist wichtig, anzuerkennen, dass der Job eines CIOs (das Managen der IT-Funktion) sowohl wichtig als auch schwierig ist.

Das Problem ist: Der CIO ist ganz und gar dazu da, dem Business zu dienen.

Genau das, was einen starken CIO ausmacht, kann leicht dazu führen, dass die unternehmerischen Ansätze zur Transformation unterminiert werden.

So erkläre ich mir, warum ich es als sehr schwierig erlebt habe, CIOs – selbst starke CIOs – dazu zu bringen, Einstellungen, Methoden und Praktiken von starken Tech-Unternehmen wertzuschätzen oder sich gar anzueignen.

Dazu kommt, dass die Produktentwickler – diejenigen, von denen die Zukunft Ihres Unternehmens abhängt – nur selten bereit sind, für einen CIO zu arbeiten, eben weil sie wissen, dass diese unterschiedlichen Einstellungen wichtig sind.

(Software-)Entwickler in einer CIO-Organisation spielen eine ganz andere Rolle als Entwickler in einer CTO-Organisation. Es ist der Unterschied zwischen Feature Teams und Product Teams mit Empowerment.

In einigen Fällen habe ich den CIO dazu ermuntert, sich zum CTO umzubenennen (weil ich glaubte, die Person sei den Herausforderungen dieser viel umfassenderen und umfangreicheren Rolle gewachsen), in anderen Fällen habe ich den CEO stark dazu ermuntert, für die Leitung des Product Developments einen wirklichen CTO einzustellen.

Anmerkungen

1

https://a16z.vom/201108/20/why-software-is-eating-the-world/

.

2

https://www.bloomberg.com/news/articles/2019-06-28/boeing-s-737-max-software-outsourced-to-9-an-hour-engineers

.

3

Bob Lutz, Car Guys vs. Bean Counters: The Battle for the Soul of American Business (New York: Portfolio/Penguin, 2013)

.

3Starkes Product Leadership

Im Zentrum dieses Buches steht die Bedeutung von starkem Product Leadership.

Mit »Product Leadership« meine ich die Führungskräfte und Manager des Product Managements, des Product Designs1 und des Engineerings.

Ich werde im Folgenden zwischen Führungskraft und Manager unterscheiden. Sicherlich sind viele Führungskräfte auch Manager und viele Manager auch Führungskräfte, aber selbst wenn beide Aufgaben von derselben Person übernommen werden, gibt es unterschiedliche Verantwortungsbereiche.

Von Leadership erwarten wir Inspiration. Die Aufgabe des Managements ist die Umsetzung von Vorgaben.

Die Aufgabe des Leaderships – Inspiration

Starkes Leadership ist natürlich ein wichtiges Thema, aber auch hier gibt einen klaren und sichtbaren Unterschied zwischen starken (Tech-)Unternehmen und den meisten Unternehmen.

Die Aufgabe eines starken Leaderships ist es, die Organisation zu inspirieren und zu motivieren.

Wenn Product Teams zu guten Entscheidungen befähigt werden sollen, müssen sie den strategischen Kontext kennen, der für eine gute Entscheidung nötig ist.

Ein Teil dieses strategischen Kontextes kommt von der Unternehmensleitung, so zum Beispiel die Mission und die wichtigsten Geschäftsziele. Product Leadership hingegen hat vier wichtige, explizite Verantwortlichkeiten:

Produktvision und -prinzipien

Die Produktvision beschreibt die Zukunft, die wir zu erschaffen versuchen, und vor allem, wie sie das Leben unserer Kunden verbessert.

Sie reicht gewöhnlich drei bis zehn Jahre in die Zukunft. Die Produktvision dient dem Technologie-Unternehmen als gemeinsames Ziel.

Es mag ganz unterschiedlich viele, funktionsübergreifende, »empowered« Product Teams geben – von ein paar wenigen in einem Start-up bis zu Hunderten in einem großen Konzern –, aber sie alle müssen in dieselbe Richtung arbeiten und auf ihre Art ihren Beitrag zur Lösung des größeren Problems leisten.

Einige Unternehmen bezeichnen die Produktvision als ihren »Nordstern« – so dass man immer, egal, in welchem Product Team man arbeitet und welches spezielle Problem man gerade zu lösen versucht, den Nordstern sehen und ihm folgen kann. Man weiß immer, welchen Beitrag der eigene Anteil zum großen Ganzen liefert.

Allgemeiner gesprochen ist die Produktvision das, was uns fortlaufend inspiriert und dazu motiviert, jeden Tag zur Arbeit zu kommen – Monat für Monat, Jahr für Jahr.

Die Produktvision ist es auch, die bei der Gewinnung von kompetenten neuen Mitarbeitern im Product Team eine entscheidende Rolle spielt.

Produktprinzipien ergänzen die Produktvision. Sie definieren den Kern von Produkten, an die das Unternehmen glaubt. Die Prinzipien spiegeln die Werte der Organisation wider, und sie bieten strategische Orientierungshilfen, die den Teams dabei helfen, die richtigen Entscheidungen zu treffen, wenn sie in schwierige Zielkonflikte geraten.

Team Topology

Die »Team Topology« definiert, wie wir die Arbeit unter verschiedenen Product Teams aufteilen, um sie am besten zu großartiger Arbeit zu befähigen. Darunter fallen die Struktur und die Aufgabenbereiche von Teams sowie ihre Beziehungen untereinander.

Product Strategy

Die Product Strategy (Produktstrategie) beschreibt die Planung, mit der wir die Produktvision erreichen und gleichzeitig die unternehmerischen Anforderungen bedienen wollen. Die Strategie leitet sich vom Fokus ab. Sie nutzt Erkenntnisse und übersetzt sie in Maßnahmen. Und sie steuert die Bearbeitung bis zur Fertigstellung.

Product Evangelism

Eine andere wichtige Rolle der Führungskraft ist die Kommunikation von Produktvision und -prinzipien und der Produktstrategie – sowohl in der internen Produktorganisation als auch weitergehend im ganzen Unternehmen.

John Doerr, der berühmte Risikokapital-Anleger, erklärt gern: »Wir brauchen Teams von Missionaren, nicht Teams von Söldnern.«

Wenn wir Teams von Missionaren wollen, ist es äußerst wichtig, dass alle Personen in der Organisation die Vision, Prinzipien und Strategie verstehen und davon überzeugt sind. Das heißt: Sie müssen wahre Gläubige sein.

Das braucht eine durchgängigen Missionierungs-Arbeit – beim Recruiting, beim Onboarding, beim wöchentlichen 1:1-Coaching, bei den Team Meetings, den Team-Mittagessen und bei allem, was es sonst noch gibt.

Je größer die Organisation, desto wichtiger ist eine sehr gute Missionierungsarbeit, und für Führungskräfte ist es äußerst wichtig zu verstehen, dass Missionierung niemals »fertig« ist. Sie muss eine Konstante sein.

Ziel ist, dass jeder Einzelne zu dieser Produktorganisation gekommen ist, weil er aufrichtig an das größere Ziel glaubt.

Üblicherweise ist die Produktvision dafür entscheidend, welche Menschen an Bord kommen. In jedem Fall müssen wir sicherstellen, dass die Menschen im Team wahre Gläubige sind.

Wenn es zum Beispiel Ihre Vision ist, Elektroautos für den Massenmarkt zu produzieren, dann brauchen Sie Menschen, die bereit sind, den Sprung zu wagen und daran zu glauben, dass dies möglich und lohnenswert ist. Dabei ist es kein Problem, wenn Sie jemanden einstellen, der eine andere Sichtweise darauf hat, was genau zu tun ist, um zu Autos für den Massenmarkt zu kommen. Nicht so hilfreich wäre es aber beispielsweise, einen leidenschaftlichen Verfechter von Verbrennungsmotoren einzustellen.

Die Aufgabe des Managements – Execution

Es gibt natürlich viele Arten von »Managern« in einem Unternehmen. Ich interessiere mich hier besonders für jene Leute, die für die Einstellung und Entwicklung der Mitarbeiter in funktionsübergreifenden Product Teams verantwortlich sind.

Normalerweise fallen darunter der Director of Product Management, der Director of Product Design und die Managers oder Directors of Engineering. Ich betrachte hier nicht die Manager auf den höheren Führungsebenen (Manager der Manager) oder Manager ohne Führungsverantwortung für Menschen (wie Product Manager oder Product Marketing Manager).

Wenn Sie wirklich empowered Product Teams haben wollen, dann hängt Ihr Erfolg direkt von jenen Managern auf der ersten Ebene ab, die Menschen führen.

Wenn Sie sich fragen, warum es so viele schwache Tech-Unternehmen auf der Welt gibt, wären dies die Hauptverantwortlichen. Und solange dies nicht korrigiert wird, gibt es wenig Hoffnung auf Transformation.

Es ist wichtig, dass diese Manager die von der obersten Geschäftsführung kommenden Produktvisionen und -prinzipien und die Produktstrategie verstehen – und sie effektiv vermitteln können. Darüber hinaus haben diese Manager drei äußerst wichtige Verantwortlichkeiten:

Stellenbesetzung

Diese Manager sind für das Staffing (die Stellenbesetzung) der Product Teams verantwortlich. Dies bedeutet, dass die Mitglieder eines Teams gesucht, angeworben, interviewt, eingearbeitet, bewertet, befördert und gegebenenfalls ersetzt werden müssen.

Wenn Sie eine HR-Abteilung in Ihrem Unternehmen haben, kann sie den Manager bei diesen Aktivitäten unterstützen – aber sie kann ihn nicht ersetzen.

Coaching

Das vielleicht allerwichtigste, doch meistens übersehene Element für fähiges Management ist Coaching. Dazu sollte es mindestens einmal in der Woche ein 1:1-Gespräch mit den Mitarbeitern geben, die an Sie berichten.

Es ist die wichtigste Verantwortung jeder Führungskraft, die Mitarbeiter bei der Entwicklung ihrer Fähigkeiten zu unterstützen. Und das bedeutet nicht, sie zu mikromanagen. Es bedeutet, die Schwächen der Mitarbeiter zu verstehen und ihnen dabei zu helfen, aus Lektionen zu lernen und besser zu werden, ihnen Beratung und Orientierungshilfe zu bieten, Hindernisse zu entfernen und Zusammenhänge herzustellen.

Sagen wir zum Beispiel, Sie sind Product Design Manager und treffen sich wöchentlich für etwa eine Stunde mit jedem der sechs Product Designer aus den verschiedenen Product Teams, die für Sie arbeiten.

Diese sechs Product Designer sind jeweils erstklassige Mitglieder ihrer funktionsübergreifenden Product Teams (denn Design ist eine erstklassige Arbeit, und deshalb muss in enger Partnerschaft mit dem Product Manager und Entwickler (Engineer) bei der Lösung schwieriger Probleme zusammengearbeitet werden). Aber selbst wenn diese Designer außerordentlich fähig sind, wie kann von ihnen erwartet werden, dass sie auf dem Laufenden darüber sind, was in den anderen Product Teams vorgeht? Was, wenn das Design, an dem sie gerade arbeiten, auf irgendeine Art und Weise nicht gut zu den Lösungen passt, die in den anderen Teams erarbeitet werden, oder sogar unvereinbar mit ihnen ist? Vom Design Manager wird erwartet, solche sich anbahnenden Konflikte zu erkennen und die relevanten Designer zusammenzubringen, um gemeinsam das größere Bild zu betrachten und die Wirkungen der verschiedenen Lösungen auf den User zu erörtern.

Team Objectives

Die dritte Verantwortlichkeit von Führungskräften ist es, sicherzustellen, dass jedes Product Team ein oder zwei klare Objectives hat, also Zielvorgaben (die typischerweise vierteljährlich verteilt werden) mit genau erklärten Problemen, die zu lösen sind.

Diese Objectives erwachsen direkt aus der Produktstrategie – hier werden Erkenntnisse in Maßnahmen überführt.

Hier wird Empowerment, die Übertragung von Eigenverantwortung, real und bleibt nicht nur ein Schlagwort. Dem Team wird eine kleine Anzahl signifikanter Probleme zur Lösung übertragen (die Team Objectives).

Das Team erörtert diese Probleme und stellt messbare Erfolgskriterien auf (Key Results bzw. Hauptergebnisse), die es dann mit seinen Managern diskutiert. Die Manager werden diesen Prozess womöglich mit ihren Teams und anderen wiederholt durchlaufen müssen, um so die größtmögliche Deckungsgleichheit mit den allgemeinen Objectives des Unternehmens zu erzielen.

Der Lackmustest für Empowerment ist die Fähigkeit des Teams, sich selbst für die besten Lösungswege für die ihnen übertragenen Probleme zu entscheiden (also für die eigenen Team Objectives).

Es braucht starke, selbstbewusste Manager, um Mitarbeiter wirklich zu empowern und auch, um später im Hintergrund zu bleiben und das Team die Lorbeeren für ihre Erfolge einheimsen zu lassen.

Notiz

1

   In diesem Buch spreche ich von Product Design und Product Designer. Viele Unternehmen verwenden die Begriffe User Experience Design oder Customer Experience Design. Wichtig ist mir, dass Folgendes einbezogen ist: Service Design, Interaction Design, Visual Design und, für Geräte, Industrial Design.

4Empowered Product Teams

Am überraschendsten ist für mich, dass die Vorteile von starken Teams mit wirklicher Eigenverantwortung, mit echtem Empowerment, kein Geheimnis sind. Tatsächlich gibt es eine Menge Bücher und Fachartikel da draußen, die beschreiben, warum diese Art von Teams so viel effizienter in Sachen Innovation und bei der Lösung schwieriger Probleme ist.

Etliche dieser Bücher sind zwar inspirierend und lesenswert, doch haben sie die meisten Unternehmen nicht davon überzeugt, ihren Teams in irgendeiner sinnvollen Art und Weise mehr Eigenverantwortung, mehr »Empowerment« zu geben. Warum ist das so?

Wenn ich CEOs und anderen wichtigen Führungspersönlichkeiten solcher Unternehmen diese Frage stelle, lässt sich die Antwort typischerweise auf ein Wort eindampfen: Vertrauen.

Die Führungskräfte vertrauen ihren Teams nicht. Speziell glauben sie nicht, dass ihre Mitarbeiter das fachliche Niveau haben, das sie bräuchten, damit man ihnen wirklich mehr Verantwortung übertragen könnte. Also glauben sie, genau wie die anderen entscheidenden Führungskräfte kreuz und quer im Unternehmen, dass sie die Teams selbst sehr genau anleiten müssen. Dieses Management-Modell ist auch als »Command and Control« (Weisung und Kontrolle) bekannt.

Wenn ich diese Führungskräfte frage, warum sie denn dann nicht die Mitarbeiter einsetzen, denen sie mehr Eigenverantwortung zutrauen, argumentieren sie normalerweise dahin gehend, dass sie die entweder nicht finden, sie sich nicht leisten können oder dass ihr Unternehmen für die Sorte von Arbeitskräften, die über die Kompetenz der Angestellten von Google, Amazon, Apple oder Netflix verfügt, nicht attraktiv genug sei.

Ich weise dann auf die vielen mir persönlich bekannten Menschen hin, die von mit dem Background meines Gesprächspartners vergleichbaren Unternehmen zu einem der führenden gewechselt sind und deren Leistungen sich daraufhin deutlich steigerten.

Da ich mit vielen Menschen in jedem dieser Unternehmen zusammengearbeitet habe, weise ich außerdem darauf hin, wie normal und durchschnittlich die große Mehrheit der Menschen in diesen Teams der Top-Unternehmen tatsächlich ist. Vielleicht liegt der wichtige Unterschied anderswo?

Vielleicht haben diese starken Unternehmen eine andere Sichtweise darauf, wie sie das Talent der Mitarbeiter wirksam einsetzen können, um ihren ganz normalen Mitarbeitern dabei zu helfen, ihr wahres Potenzial zu entfalten und gemeinsam mit anderen ganz normalen Leuten ganz außergewöhnliche Produkte zu schaffen.

5Leadership in Aktion

Dieses Buch argumentiert, dass der Schlüssel zum Aufbau starker Technologie-Unternehmen starke Product Leader sind.

Immerhin sind dies die Leute, die verantwortlich für die Zusammenstellung der Product Teams und ihr Coaching sind, und sie sind verantwortlich für Produktvision und -prinzipien und insbesondere für die Produktstrategie, die die speziellen Probleme benennt, welche das Product Team lösen soll.

Was für Menschen sind nun diese starken Product Leader? Und wofür arbeiten sie?

In INSPIRED habe ich sechs Product Manager vorgestellt, die allesamt für kultige Produkte verantwortlich sind, jedoch weithin unbekannt waren. Ich erzählte ihre Geschichten – darunter auch die Probleme, denen sie sich gegenübersahen, und wie sie diese überwanden.

In EMPOWERED möchte ich nun dasselbe tun, aber diesmal mit Product Leadern. Ich stelle acht Product Leader vor. Jede von ihnen – es sind allesamt Frauen – hat eine außergewöhnliche Karriere bei einem kultigen Tech-Unternehmen gemacht. Doch auch hier gilt: Die meisten von ihnen sind weithin unbekannt.

Ich hebe zwei Leader of Product Management, zwei Leader of Product Design, zwei Leader of Engineering und zwei Unternehmensleiterinnen hervor.

Ich versuche nicht, vollständige Biografien vorzulegen, stattdessen bat ich jede, in ihren eigenen Worten von ihrem Weg in die Führungsverantwortung zu erzählen. Es ist meine Hoffnung, dass diese Erzählungen ein gutes Gespür für ihre Einstellung zur Mitarbeiterführung vermitteln und vor allem dafür, wie es ist, für und mit einem starken und erfahrenen Product Leader zu arbeiten.

6Ein Leitfaden zu EMPOWERED

Für wen dieses Buch ist

Dieses Buch soll für jeden sein, der oder die sich für die Schaffung eines starken Tech-Unternehmens interessiert – vom Start-up-Gründer bis zum CEO eines größeren technologiebasierten Unternehmens.

Speziell zielt dieses Buch auf Product Leader und angehende Product Leader ab, besonders auf die Leiter von Product Managern, Product Designern und (Software-)Entwicklern.

Wenn von »Produktperson« die Rede ist, so ist das normalerweise jeder im Product Management, im Product Design oder im Engineering (in der Technik/Software-Entwicklung). Die Person kann ebenso gut ein Manager sein wie jemand, der einen individuellen Beitrag leistet.

Zwar mag man viele weitere Funktionen in einem bestimmten Product Team finden – Delivery Manager, User Researcher, Data Analyst, Data Scientist und Product Marketing Manager sind die hauptsächlichen –, doch dieses Buch fokussiert sich auf die folgenden drei zentralen Funktionen: Product Manager (PM), Product Designer (Designer) und Engineering Tech Lead (Tech Lead).

Wenn Sie eine Bezugnahme auf einen »Product Leader« sehen, ist das normalerweise ein Manager/Director/VP/CPO of Product Management, Manager/Director/VP/CPO of Product Design oder ein Manager/Director/VP/CPO of Engineering (VP: Vice President; CPO: Chief Procurement Officer, Führungskraft, die für die Beschaffung von Waren und Dienstleistungen verantwortlich ist).

Wenn nicht anders erwähnt, richten sich die Ratschläge in diesem Buch an Product Leader.

Wenn einige Ratschläge sich an eine spezielle Funktion richten, wie Product Manager, Product Designer, Tech Lead oder Data Scientist, wird dies explizit erwähnt.

Während es einige funktionsspezifische Informationen für Product Designer und ihre Leader gibt sowie für Techniker und ihre Leader, gibt es mehr Informationen für Product Manager und ihre Leiter. Dies deshalb, weil die Rollen von Product Manager und Product Management Leadership, wenn sie sich zur Entwicklung von Teams mit mehr Eigenverantwortung (empowered) hinbewegen, normalerweise am weitesten von dort entfernt sind, wo sie sein müssten.

Wer spricht?

Wenn nicht anders erwähnt, ist die Stimme des Autors entweder die von Marty Cagan oder die von Chris Jones. Wir beide sind Partner in der Silicon Valley Product Group (SVGP).

Wir machen nicht kenntlich, wer von uns welche Kapitel verfasst hat, denn wir stimmen in allem, was hier geschrieben steht, überein, und wir beide waren in die vielen Schritte und Überarbeitungen involviert, die nötig waren, um vom ersten Entwurf jedes Kapitels bis zum fertigen Buch zu kommen.

Ferner fußen viele Lehren dieses Buches auf dem umfassenden Erfahrungsschatz der SVPG-Partner. Alle zusammengenommen haben wir wohl über 100 Jahre Erfahrung in der Leitung von Produktorganisationen bei vielen der Top-Tech-Unternehmen.

Wir schreiben absichtlich in der ersten Person, weil wir der Erfahrung, uns mit Ihnen an einen Tisch zu setzen, so nah wie möglich kommen wollen: für eine Reihe von Einzel-Coachings, bei denen es unser einziges Ziel ist, Ihnen dabei zu helfen, zu einem außergewöhnlich starken Product Leader zu werden.

Wie dieses Buch aufgebaut ist

Da Sie nun die Themenspanne des Buches kennen, nun hier ein Überblick seines Aufbaus:

In Teil II fokussieren wir uns auf die wichtigste Verantwortlichkeit starker Product Leader, nämlich das Coaching – die Entwicklung der Mitarbeiter in den Product Teams.

In Teil III behandeln wir die Personalbesetzung dieser Product Teams – wie diese Mitarbeiter zu finden, anzuwerben und einzustellen sind und sichergestellt werden kann, dass sie effektiv sind.

In Teil IV besprechen wir die Produktvision und -prinzipien, welche die Zukunft definieren, die wir zu erschaffen versuchen.

In Teil V schauen wir darauf, wie wir die Product Teams in eine Team Topology gliedern, die die Bedürfnisse des Unternehmens optimal erfüllt.

In Teil VI erörtern wir die Produktstrategie, also wie wir entscheiden, welches die wichtigsten zu lösenden Probleme für dieses Product Team sind.

In Teil VII setzen wir unsere Produktstrategie mit den Team Objectives (zu lösende Probleme) für jedes Product Team in die Tat um.

In Teil VIII legen wir eine detaillierte Fallstudie vor, die zeigt, wie jedes dieser Konzepte in einer komplizierten Situation in der realen Welt umgesetzt wird.

In Teil IX legen wir dar, wie die notwendige Zusammenarbeit zwischen der Produktorganisation und dem Rest des Geschäftsbetriebs etabliert wird.

In Teil X verknüpfen wir alles miteinander und geben Ihnen einen Plan für das Transformieren Ihrer Organisation an die Hand, damit alles so wie in den besten Teams und Unternehmen funktioniert.

Zwar ist die Art von Veränderung, die notwendig ist, keineswegs einfach, doch sie ist absolut möglich. Dieses Buch zielt ganz darauf ab, Ihnen das Wissen und die Fähigkeiten zu vermitteln, die Sie brauchen, um erfolgreich zu sein.

Teil IICOACHING

»Coaching ist keine Spezialität mehr; man kann kein guter Manager sein, ohne ein guter Coach zu sein.«

Bill Campbell

Bill machte diese Aussage vor Jahren, aber eine der wichtigen Lehren unserer Branche im Post-Pandemie-Zeitalter besteht darin, dass Coaching wichtiger denn je ist. Wenn Sie Innovationen hochfahren wollen, ist Coaching keine Option, sondern zwingend nötig. Probleme steigen sprunghaft an, Beziehungen werden leichter beschädigt, und die Zusammenarbeit wird schwieriger.

Dies ist der Grund dafür, dass sich der größte Teil dieses Buches mit Coaching beschäftigt. Das ist kein Zufall.

In der Technologie-Branche fokussieren wir uns so sehr auf die Kernkompetenzen und Fähigkeiten, die Product Manager, Designer und Techniker brauchen, aber so wenig auf die Fähigkeiten und Kompetenzen von Managern und Führungskräften. Doch es sind diese Manager und Führungskräfte (Leader), die dafür verantwortlich sind, Mitarbeiter zu erfolgreichen Teams zu formen.

Die Logik ist simpel: Ihr Unternehmen hängt von erfolgreichen Produkten ab. Und erfolgreiche Produkte kommen von starken Product Teams.

Coaching ist das, was gewöhnliche Menschen zu außergewöhnlichen Product Teams macht.

Wenn ein Product Team nicht erfolgreich ist, müssen wir uns die Menschen in diesem Team genau anschauen, um zu sehen, wie wir ihnen helfen können, sich als Individuum und insbesondere innerhalb des Teams zu verbessern.

Die Kapitel in diesem Teil beleuchten die wichtigsten Bereiche von Coaching und die Förderung der Mitglieder von Product Teams in ihrer Entwicklung. Sofern Sie nicht selbst schon von einem erfahrenen Manager gecoacht wurden, mögen viele Themen neu für Sie sein. Sicherlich ist es umso besser, wenn Sie bei diesen Themen aus eigener Erfahrung sprechen können, doch eine offene Diskussion lohnt sich in jedem Fall. So kann man gemeinsam lernen und besser werden.

Mehr als alles andere ist gutes Coaching ein laufender Dialog mit dem Ziel, dem Mitarbeiter dabei zu helfen, sein Potenzial voll zu entfalten.

7Die geistige Haltung des Coachings

»Coaching mag für unsere Karrieren und unsere Teams noch wichtiger als Mentoring sein. Während Mentoren sparsam Weisheiten von sich geben, krempelt ein Coach die Ärmel hoch und macht sich die Hände schmutzig. Ein Coach glaubt nicht nur an unser Potenzial; er geht mit in den Ring, um uns dabei zu helfen, unser Potenzial zu entfalten. Er hält uns einen Spiegel vor, so dass wir unsere blinden Flecken sehen können, und er sorgt dafür, dass wir uns durch die wunden Punkte durcharbeiten. Er übernimmt die Verantwortung dafür, dass wir besser werden, ohne die Lorbeeren für das, was wir erreichen, einheimsen zu wollen.«

Bill Campbell

In diesem Kapitel möchte ich mich weniger auf die Menschen fokussieren, die Sie zu coachen versuchen, sondern auf Ihre dazu notwendige Geisteshaltung als Coach.

Die falsche Geisteshaltung mag Sie ansonsten vielleicht dazu verleiten, diese Methoden dergestalt anzuwenden, dass sie tatsächlich kontraproduktiv für das Ziel sind.

Zum Beispiel engagieren Sie sich vielleicht für regelmäßige Eins-zu-eins-Treffen mit jedem Ihrer Team-Mitglieder, aber wenn diese Treffen hauptsächlich darin bestehen, dass Sie Aufgaben verteilen und priorisieren, sind sie nicht hilfreich – und als Coaching-Werkzeug wahrscheinlich sogar schädlich.

Die Geisteshaltung des Coachings bedeutet eine Absichtsgrundlage. Sie bildet den Rahmen, der Ihre Anwendung von Coaching-Techniken bestimmt, und ist Ihre Richtschnur für das Handeln und für Entscheidungen rund um die Förderung und Begleitung eines Teams bei seiner Entwicklung.

Wenn Sie ein erfahrener Coach oder Manager sind, haben Sie vielleicht schon Ihren eigenen Satz an Prinzipien entwickelt. Wenn dies nicht der Fall ist, Sie neu im Management oder für die Entwicklung eines neuen Managers verantwortlich sind, versucht dieses Kapitel die wichtigsten Richtlinien für Coaching und Management zu beschreiben.

Job Nr. 1: Menschen bei ihrer Entwicklung fördern