{"id":10116,"date":"2026-07-24T14:23:16","date_gmt":"2026-07-24T12:23:16","guid":{"rendered":"https:\/\/cohive.works\/?p=10116"},"modified":"2026-07-27T13:08:18","modified_gmt":"2026-07-27T11:08:18","slug":"methode-oder-werkzeug-der-unterschied-den-die-meisten-in-organisationen-ubersehen","status":"publish","type":"post","link":"https:\/\/cohive.works\/de\/methode-oder-werkzeug-der-unterschied-den-die-meisten-in-organisationen-ubersehen\/","title":{"rendered":"Methode oder Werkzeug? Der Unterschied, den die meisten in Organisationen \u00fcbersehen"},"content":{"rendered":"

[vc_row css_animation=““ row_type=“row“ use_row_as_full_screen_section=“no“ type=“full_width“ angled_section=“no“ text_align=“left“ background_image_as_pattern=“without_pattern“ z_index=““][vc_column][vc_empty_space height=“30px“][vc_single_image image=“10133″ img_size=“full“ css=““ qode_css_animation=““][vc_empty_space height=“15px“][vc_column_text css=““]Die meisten von uns kennen das Gef\u00fchl. Man sitzt in einer Schulung f\u00fcr mehr Agilit\u00e4t oder lernt eine neue Methode, mit der andere Unternehmen angeblich Wunder vollbracht haben, und kehrt hoch motiviert in den Alltag zur\u00fcck. Dann stellt sich heraus, dass genau das, was im Lehrbuch so sauber funktioniert hat, im eigenen Team einfach nicht greift, und man fragt sich, ob man selbst etwas falsch gemacht hat oder ob am eigenen Team etwas nicht stimmt. <\/p>\n

Ich sehe es in fast jeder Organisation, mit der ich zusammenarbeite: Regale voller Methoden oder \u201ePlaybooks\u201c, wie manche sie nennen. Scrum, OKRs, was auch immer beim Offsite-Meeting im letzten Quartal herausgekommen ist. Und doch tauchen immer wieder dieselben Probleme auf, nur unter neuen Namen. Der Grund daf\u00fcr ist selten die falsche Methode. Es ist eine Verwechslung, die fast niemand direkt beim Namen nennt: der Unterschied zwischen einer Methode und einem Tool bzw. Werkzeug. Methode oder Werkzeug, das ist die eigentliche Frage. Wie du sie beantwortest, ist wichtiger als die Frage, welche Methode du w\u00e4hlst.[\/vc_column_text][vc_empty_space height=“100px“][vc_column_text css=““]<\/p>\n

Inhalt<\/h2>\n

[\/vc_column_text][vc_column_text css=““]Was eine Methode wirklich ist: Das Rezept, das Gewissheit und Sicherheit verspricht<\/a><\/p>\n

Was ein Werkzeug ist: Es liefert die Ausf\u00fchrung, nicht die Entscheidung<\/a><\/p>\n

Methode oder Werkzeug (Tool): Eine Frage von roten und blauen Problemen<\/a><\/p>\n

Warum aus einem Werkzeug so leicht eine Methode wird<\/a><\/p>\n

Methode oder Tool in der Praxis: Zwei Beispiele, die es wert sind, n\u00e4her betrachtet zu werden<\/a><\/p>\n

Fazit: Warum Methode oder Werkzeug (Tool) eine zentrale Unterscheidung im Organisationsalltag ist<\/a>[\/vc_column_text][vc_empty_space height=“100px“][\/vc_column][\/vc_row][vc_row css_animation=““ row_type=“row“ use_row_as_full_screen_section=“no“ type=“full_width“ angled_section=“no“ text_align=“left“ background_image_as_pattern=“without_pattern“ z_index=““ anchor=“what-a-method-really-is“][vc_column][vc_column_text css=““]<\/p>\n

Was eine Methode wirklich ist: Das Rezept, das Gewissheit und Sicherheit verspricht<\/h2>\n

[\/vc_column_text][vc_empty_space height=“15px“][vc_column_text css=““]<\/p>\n

Die Grundidee<\/h3>\n

Eine Methode ist im Kern ein Rezept, das Wissen zusammenfasst, das sich in der Vergangenheit bew\u00e4hrt hat, und dieses Wissen in eine feste Abfolge von Schritten verpackt: <\/p>\n

1\ufe0f\u20e3 Mach das hier
\n2\ufe0f\u20e3 Dann das hier
\n3\ufe0f\u20e3 Und dann das<\/p>\n

Genau darin liegt ihre Anziehungskraft, denn eine Methode nimmt einem die Entscheidung ab. Man muss nicht mehr selbst beurteilen, was in dieser Situation zu tun ist, sondern kann der Vorgabe folgen, die jemand anderes bereits f\u00fcr einen durchdacht hat. <\/p>\n

Wo das gut funktioniert<\/h3>\n

Das funktioniert hervorragend, solange sich eine Situation zuverl\u00e4ssig wiederholt. Denk zum Beispiel an einen Fertigungsprozess mit bekannten Schwachstellen, eine Buchhaltung, die klaren gesetzlichen Vorschriften unterliegt, oder einen Einarbeitungsprozess mit einer festgelegten Abfolge. In solchen F\u00e4llen ersetzt eine gute Methode jahrelange Erfahrung durch eine Anleitung, der jeder folgen kann, ohne selbst \u00fcber Jahre Urteilsverm\u00f6gen aufbauen zu m\u00fcssen. <\/p>\n

Wo es schiefgeht<\/h3>\n

Sobald eine Situation aber neu ist und \u00fcberrascht, wird genau diese St\u00e4rke zur Schw\u00e4che, weil eine Methode nur die Antworten liefern kann, die bereits in ihr enthalten sind. Trifft sie auf ein Problem, das es in dieser Form noch nicht gab, hat sie keine Antwort, sondern nur die Illusion einer Antwort, was in der Praxis oft schlimmer ist, als gar keine Methode zu haben. <\/p>\n

Warum das immer h\u00e4ufiger passiert<\/h3>\n

Solche Situationen werden nicht seltener. Sie kommen immer h\u00e4ufiger vor. Dr. Gerhard Wohland, Physiker und Unternehmensberater, beobachtet das schon seit Jahrzehnten. Fr\u00fcher wuchsen Unternehmen haupts\u00e4chlich durch Globalisierung: neue M\u00e4rkte, neue Kunden, ohne dass sich am eigentlichen Gesch\u00e4ft viel \u00e4ndern musste. Heute sind die globalen M\u00e4rkte in den meisten Branchen weitgehend ges\u00e4ttigt. Wachstum kommt mittlerweile weniger von neuen M\u00e4rkten, sondern eher davon, dass Unternehmen sich gegenseitig mit besseren Ideen die bestehenden Kunden abjagen. Das f\u00fchrt zu einer Dynamik, in der Wettbewerbsvorteile schneller verpuffen und Probleme seltener genau in der Form wiederkehren, wie man sie schon kennt \u2013 und genau hier scheitern vorgefertigte Rezepte zwangsl\u00e4ufig. <\/p>\n

Keine Abwertung von Methoden<\/h3>\n

Gute Beratung, Coaching und Organisationsentwicklung arbeiten methodenagnostisch, das hei\u00dft, sie setzen Methoden dort ein, wo eine Situation tats\u00e4chlich bekannt und wiederholbar ist, und wechseln zum Werkzeug, sobald das nicht mehr zutrifft. Das eigentliche Problem ist nicht die Methode an sich. Es ist die Annahme, dass eine einzige Methode jede Situation gleicherma\u00dfen gut abdecken kann.<\/p>\n

[\/vc_column_text][vc_empty_space height=“100px“][\/vc_column][\/vc_row][vc_row css_animation=““ row_type=“row“ use_row_as_full_screen_section=“no“ type=“full_width“ angled_section=“no“ text_align=“left“ background_image_as_pattern=“without_pattern“ z_index=““ anchor=“what-a-tool-really-is“][vc_column][vc_column_text css=““]<\/p>\n

Was ein Werkzeug ist: Es liefert die Ausf\u00fchrung, nicht die Entscheidung<\/h2>\n

[\/vc_column_text][vc_empty_space height=“30px“][vc_single_image image=“10143″ img_size=“full“ css=““ qode_css_animation=““][vc_empty_space height=“15px“][vc_column_text css=““]<\/p>\n

Die Grundidee<\/h3>\n

Ein Werkzeug funktioniert anders, weil es schweigt: Es sagt nicht, wof\u00fcr es eingesetzt werden soll, sondern wartet darauf, dass jemand eine Idee mitbringt oder ein Problem hat, das gel\u00f6st werden muss. Ein Werkzeug tr\u00e4gt deshalb auch keine Autorit\u00e4t in sich, die Autorit\u00e4t bleibt bei der Person, die es benutzt, und genau das unterscheidet es grundlegend von einer Methode. <\/p>\n

Der \u201eHammer\u201c-Einwand<\/h3>\n

An dieser Stelle lohnt sich ein Einwand, der oft zu Recht kommt: Ein Hammer ist doch zum H\u00e4mmern da. Hat ein Werkzeug also nicht sehr wohl einen eingeschriebenen Zweck? Ja, aber nur auf einer bestimmten Ebene. <\/p>\n

Ein Hammer sagt dir:<\/strong><\/p>\n

\u2705 So schwingst du ihn: am Kopf, nicht am Griff<\/p>\n

Wor\u00fcber er aber schweigt:<\/strong><\/p>\n

\u274c Ob du \u00fcberhaupt h\u00e4mmern solltest
\n\u274c Wo der Nagel hingeh\u00f6rt
\n\u274c Ob ein Nagel das richtige Befestigungsmittel f\u00fcr die Aufgabe ist
\n\u274c Was du damit eigentlich baust<\/p>\n

Wo die Entscheidung wirklich liegt<\/h3>\n

Diese Fragen bleiben bei der Person, die \u00fcberhaupt erst entscheidet, ob sie den Hammer in die Hand nimmt. Ein Werkzeug \u00fcbernimmt also die operative Ausf\u00fchrung, das Wie, aber die Entscheidung, ob eine Handlung in dieser Situation \u00fcberhaupt sinnvoll ist, bleibt bei dem Menschen, der es in der Hand h\u00e4lt, bei jemandem mit genug Erfahrung und Urteilsverm\u00f6gen, um das zu beurteilen. <\/p>\n

K\u00f6nnen statt Wissen<\/h3>\n

Dr. Wohland nennt diese F\u00e4higkeit K\u00f6nnen, im Unterschied zu Wissen, das dokumentierbar und \u00fcbertragbar ist, etwa in einem Handbuch oder einer Checkliste. K\u00f6nnen l\u00e4sst sich dagegen nicht aufschreiben, es zeigt sich nur im Handeln selbst. Einen K\u00f6nner erkennt man deshalb nicht an einem Zertifikat oder einer Ausbildung, sondern daran, dass er in einer Situation, die er in dieser Form noch nie gesehen hat, trotzdem eine brauchbare Idee entwickelt, und genau das unterscheidet ihn von jemandem, der nur eine Methode auswendig gelernt hat. <\/p>\n

Die drei Ebenen im Detail<\/h3>\n

Das l\u00e4sst sich noch etwas pr\u00e4ziser fassen, wie schon am Hammer gezeigt: Das operative Wie ist bei einem Werkzeug festgelegt, genau wie bei einer Methode auch, das macht an dieser Stelle also noch keinen Unterschied. Der Unterschied zeigt sich erst bei den beiden Ebenen danach: Das situative Ob und Wann bleibt bei einem Werkzeug offen und liegt beim Anwender, und das strategische Warum bleibt ebenfalls offen und bleibt beim K\u00f6nner. Eine Methode dagegen beansprucht, auch diese beiden Ebenen zu kennen, sie sagt nicht nur, wie etwas getan wird, sondern auch, wann es zu tun ist und warum es die richtige Wahl ist. <\/p>\n

Offen bleibt bei einem echten Werkzeug meistens sogar noch eine vierte Frage, n\u00e4mlich das Was, also der eigentliche Inhalt der L\u00f6sung. Ein Handwerker, der mit demselben Hammer ein Regal baut, setzt ihn v\u00f6llig bestimmungsgem\u00e4\u00df ein und trifft trotzdem bei jedem einzelnen Nagel eine eigene Entscheidung, wo er sitzt und warum genau dort. Und derselbe Hammer kann ebenso eine T\u00fcr aufhalten, als Briefbeschwerer dienen oder im Zweifel sogar als Hebel herhalten, welche dieser M\u00f6glichkeiten sinnvoll ist, entscheidet allein die Idee der Person, die ihn gerade in der Hand h\u00e4lt, nicht das Werkzeug selbst. Das Werkzeug schreibt diesen Inhalt also nicht vor, ob die Idee dazu schon vorher feststeht oder sich erst w\u00e4hrend der Anwendung entwickelt, spielt dabei keine Rolle, entscheidend ist nur, dass diese Entscheidung nie im Werkzeug selbst liegt, sondern immer bei der Person, die es einsetzt. Genau dort verschiebt sich die Entscheidungsmacht vom Menschen auf das Regelwerk, sobald eine Methode auch das noch f\u00fcr sich beansprucht.[\/vc_column_text][vc_empty_space height=“30px“][vc_column_text css=““]<\/p>\n\n\n\n\n\n\n\n\n
Stufe<\/th>\nWerkzeug<\/th>\nMethode<\/th>\n<\/tr>\n<\/thead>\n
Operatives Wie<\/strong><\/td>\nvorgegeben<\/td>\nvorgegeben<\/td>\n<\/tr>\n
Situatives Ob & Wann<\/strong><\/td>\noffen, liegt beim Nutzer<\/td>\nvorgeschrieben<\/td>\n<\/tr>\n
Strategisches Warum<\/strong><\/td>\noffen, bleibt beim erfahrenen K\u00f6nner<\/td>\nbehauptet, es zu wissen<\/td>\n<\/tr>\n
Was (Inhalt der L\u00f6sung)<\/strong><\/td>\noffen, entsteht bei der Person<\/td>\nist meist vorgegeben<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

[\/vc_column_text][vc_empty_space height=“30px“][vc_column_text css=““]<\/p>\n

Der Vorteil bei \u00dcberraschungen<\/h3>\n

Darin liegt auch der Vorteil, wenn eine Situation \u00fcberrascht: Ein Werkzeug bricht nicht zusammen, wenn die Realit\u00e4t von der Erwartung abweicht, weil es nie behauptet hat, die Antwort zu kennen, sondern lediglich Mittel zur Verf\u00fcgung stellt, mit denen ein K\u00f6nner eine eigene Antwort entwickeln kann. <\/p>\n

Auf einen Blick<\/h3>\n

[\/vc_column_text][vc_empty_space height=“30px“][vc_column_text css=““]<\/p>\n\n\n\n\n\n\n\n\n\n
Dimension<\/th>\nWerkzeug<\/th>\nMethode<\/th>\n<\/tr>\n<\/thead>\n
Haltung<\/strong><\/td>\nNeutral, wartet auf eine Idee<\/td>\nSchreibt vor, was zu tun ist<\/td>\n<\/tr>\n
Voraussetzung<\/strong><\/td>\nUnbekannte, komplexe Situation<\/td>\nBekannte, wiederholbare Situation<\/td>\n<\/tr>\n
Autorit\u00e4t<\/strong><\/td>\nLiegt beim Nutzer<\/td>\nLiegt in der Methode selbst<\/td>\n<\/tr>\n
Reaktion auf \u00dcberraschungen<\/strong><\/td>\nBleibt anpassungsf\u00e4hig<\/td>\nScheitert<\/td>\n<\/tr>\n
Risiko<\/strong><\/td>\nErfordert K\u00f6nnen<\/td>\nBusiness-Theater und Zynismus<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

[\/vc_column_text][vc_empty_space height=“30px“][vc_column_text css=““]<\/p>\n

Das Scrum-Beispiel<\/h3>\n

Scrum veranschaulicht das gut. Scrum als Methode sagt: Sprints dauern zwei Wochen, das Daily dauert f\u00fcnfzehn Minuten, am Ende jedes Sprints steht eine Retrospektive. Scrum als Werkzeug sagt dagegen etwas anderes, n\u00e4mlich dass ein Rhythmus aus kurzen Iterationen und regelm\u00e4\u00dfiger Reflexion in bestimmten Kontexten helfen kann, wobei das Team selbst entscheidet, wie oft, wie lang, ob \u00fcberhaupt, und vor allem, was inhaltlich am Ende dabei herauskommt. <\/p>\n

Diese Tabellen machen zusammen deutlich, dass der Unterschied nicht davon abh\u00e4ngt, wie gut ein Konzept an sich ist, sondern davon, wer am Ende die Verantwortung f\u00fcr die Entscheidung tr\u00e4gt, sei es bei einem KVP-Board oder einem Scrum-Rhythmus. Fast jedes dieser Konzepte kann beides sein, Werkzeug oder Methode, je nachdem, wie eine Organisation tats\u00e4chlich damit umgeht.[\/vc_column_text][vc_empty_space height=“100px“][\/vc_column][\/vc_row][vc_row css_animation=““ row_type=“row“ use_row_as_full_screen_section=“no“ type=“full_width“ angled_section=“no“ text_align=“left“ background_image_as_pattern=“without_pattern“ z_index=““ anchor=“method-or-zool-question-of-red-and-blue-problems“][vc_column][vc_column_text css=““]<\/p>\n

Methode oder Werkzeug (Tool): Eine Frage von roten und blauen Problemen<\/h2>\n

[\/vc_column_text][vc_empty_space height=“30px“][vc_single_image image=“10144″ img_size=“full“ css=““ qode_css_animation=““][vc_empty_space height=“15px“][vc_column_text css=““]Diese Unterscheidung wird noch greifbarer, wenn man sie durch die Linse von roten und blauen Problemen betrachtet, denn beide beschreiben im Kern dieselbe Logik aus zwei verschiedenen Blickwinkeln.<\/p>\n

Blaue Probleme<\/strong> sind kompliziert, aber bekannt. Das Wissen, um sie zu l\u00f6sen, ist bereits vorhanden \u2013 man muss es nur anwenden. <\/p>\n

Rote Probleme<\/strong> sind komplex und neu. Die Antwort gibt es noch nicht. Sie muss erst entstehen \u2013 durch Ideen, durch K\u00f6nnen und durch Zusammenarbeit. <\/p>\n

Was daraus folgt<\/h3>\n

Eine Methode ist f\u00fcr blaue Probleme gedacht, weil sie auf bereits vorhandenem Wissen aufbaut. Werkzeuge bzw. Tools hingegen sind f\u00fcr rote Probleme gedacht, weil sie keine vorgefertigte Antwort liefern, sondern nur die Mittel, mit denen ein erfahrener K\u00f6nner eine solche entwickeln kann. <\/p>\n

Wo das in der Praxis schiefgeht<\/h3>\n

Die meisten Unternehmen scheitern nicht, weil sie die falsche Methode gew\u00e4hlt haben. Sie scheitern, weil sie ein rotes Problem mit einem blauen Rezept l\u00f6sen wollen \u2013 oder umgekehrt ein blaues Problem der Beliebigkeit eines offenen Werkzeugs \u00fcberlassen, wo eine klare Anleitung schneller zum Ziel gef\u00fchrt h\u00e4tte. Und weil es meistens F\u00fchrungskr\u00e4fte sind, die entscheiden, welche Methode im Team eingef\u00fchrt wird, oft frisch inspiriert vom letzten Konferenzvortrag oder dem neuesten Management-Bestseller, lohnt sich f\u00fcr sie ein genauerer Blick auf diese Unterscheidung, bevor die n\u00e4chste Methode eingef\u00fchrt wird, denn wer zuerst fragt, ob ein Problem \u00fcberhaupt neu ist, sucht danach auch nach der richtigen Antwort, nicht nur nach der n\u00e4chstbesten Anleitung.[\/vc_column_text][vc_empty_space height=“100px“][\/vc_column][\/vc_row][vc_row css_animation=““ row_type=“row“ use_row_as_full_screen_section=“no“ type=“full_width“ angled_section=“no“ text_align=“left“ background_image_as_pattern=“without_pattern“ z_index=““ anchor=“why-a-tool-turns-into-a-method-easily“][vc_column][vc_column_text css=““]<\/p>\n

Warum aus einem Werkzeug so leicht eine Methode wird<\/h2>\n

[\/vc_column_text][vc_empty_space height=“30px“][vc_single_image image=“10145″ img_size=“full“ css=““ qode_css_animation=““][vc_empty_space height=“15px“][vc_column_text css=““]<\/p>\n

Wie es passiert<\/h3>\n

Die Verwechslung entsteht meistens auf dieselbe Weise: Jemand beobachtet, wie ein Werkzeug in einer bestimmten Organisation gut funktioniert, beschreibt anschlie\u00dfend die einzelnen Schritte, mit denen es dort eingesetzt wurde, und verpackt sie als Anleitung. Aus dem Werkzeug wird so eine Methode, mit allem, was dazugeh\u00f6rt: fester Reihenfolge, festen Rollen, festen Zeitfenstern. <\/p>\n

Warum das nicht funktioniert<\/h3>\n

Das eigentliche Problem dabei ist nicht die Beschreibung selbst, sondern der Anspruch, der damit einhergeht. Die urspr\u00fcngliche Situation war spezifisch, das Werkzeug hat dort funktioniert, weil jemand es genau an diesen Kontext angepasst hat. Die neue Methode dagegen erhebt den Anspruch, \u00fcberall zu funktionieren, unabh\u00e4ngig vom Kontext, und genau das kann sie nicht einl\u00f6sen. <\/p>\n

Kein Einzelfall<\/h3>\n

Das gleiche Muster l\u00e4sst sich bei vielen F\u00fchrungskonzepten beobachten, die mehr versprechen als sie halten<\/a>, wenn ein Prinzip aus einem einzelnen erfolgreichen Unternehmen zur allgemeing\u00fcltigen Blaupause f\u00fcr alle erkl\u00e4rt wird und dabei genau die Flexibilit\u00e4t verliert, die es urspr\u00fcnglich wertvoll gemacht hat.[\/vc_column_text][vc_empty_space height=“100px“][\/vc_column][\/vc_row][vc_row css_animation=““ row_type=“row“ use_row_as_full_screen_section=“no“ type=“full_width“ angled_section=“no“ text_align=“left“ background_image_as_pattern=“without_pattern“ z_index=““ anchor=“method-or-tool-in-practice“][vc_column][vc_column_text css=““]<\/p>\n

Methode oder Werkzeug (Tool) in der Praxis: Zwei Beispiele, die es wert sind, n\u00e4her betrachtet zu werden<\/h2>\n

[\/vc_column_text][vc_empty_space height=“30px“][vc_single_image image=“10146″ img_size=“full“ css=““ qode_css_animation=““][vc_empty_space height=“15px“][vc_column_text css=““]<\/p>\n

Das KVP-Board<\/h3>\n

F\u00fchrt eine F\u00fchrungskraft es als starre Methode ein, mit festem Schema und festen Schritten, wird es schnell zweckentfremdet. Mitarbeitende, die sich der Methode verweigern, nutzen das Board dann als eine Art Klagemauer, um Anschaffungen durchzusetzen, die sonst blockiert worden w\u00e4ren, weil die tats\u00e4chliche Situation komplexer war, als das Rezept angenommen hat. <\/p>\n

Der Kulturwandel<\/h3>\n

Am deutlichsten wird es hier, denn Kultur l\u00e4sst sich nicht mit einer Methode ver\u00e4ndern, weil kein Kulturfall dem anderen gleicht. Wer verspricht, Kultur in drei Schritten zu ver\u00e4ndern, behandelt ein rotes Problem, als w\u00e4re es blau. Kultur besteht aus Mustern, die sich \u00fcber viele Entscheidungen hinweg eingespielt haben, aber selbst nie explizit entschieden wurden, wie Niklas Luhmann das beschrieben hat, und genau deshalb l\u00e4sst sie sich nicht direkt anordnen. Kultur braucht keine Anleitung, sie braucht K\u00f6nner, die mit den richtigen Werkzeugen an den richtigen Strukturen ansetzen. Nur dar\u00fcber ver\u00e4ndert sich Kultur indirekt, genau wie es auch F\u00fchrungskr\u00e4fteentwicklung als Strukturarbeit statt Verhaltenstraining<\/a> zeigt.[\/vc_column_text][vc_empty_space height=“100px“][\/vc_column][\/vc_row][vc_row css_animation=““ row_type=“row“ use_row_as_full_screen_section=“no“ type=“full_width“ angled_section=“no“ text_align=“left“ background_image_as_pattern=“without_pattern“ z_index=““ anchor=“conclusion“][vc_column][vc_column_text css=““]<\/p>\n

Fazit: Warum Methode oder Werkzeug eine zentrale Unterscheidung im Organisationsalltag ist<\/h2>\n

[\/vc_column_text][vc_empty_space height=“15px“][vc_column_text css=““]Bevor du morgen eine neue Methode, eine neue Vorlage oder ein neues Framework einf\u00fchrst, stell dir zuerst diese eine Frage: Handelt es sich um ein bekanntes, wiederholbares Problem oder um ein neues, f\u00fcr das es noch keine L\u00f6sung gibt? Im ersten Fall ist eine Methode mit festen Anweisungen und einer klaren Struktur v\u00f6llig in Ordnung. Es lohnt sich aber trotzdem, sie an deinen eigenen Kontext anzupassen, anstatt sie pauschal zu \u00fcbernehmen, denn selbst eine bekannte, wiederholbare Situation ist selten identisch mit der, aus der die Methode urspr\u00fcnglich stammt. Im zweiten Fall brauchst du Werkzeuge und einen K\u00f6nner \u2013 jemanden, der die Entscheidung dort l\u00e4sst, wo sie hingeh\u00f6rt: n\u00e4mlich bei den Menschen, die die Situation tats\u00e4chlich einsch\u00e4tzen k\u00f6nnen. <\/p>\n

Die eigentliche Aufgabe der F\u00fchrung besteht darin, diese Unterscheidung im Team lebendig zu halten, anstatt sie stillschweigend an die n\u00e4chsten Anweisungen bzw. Anleitungen weiterzugeben.[\/vc_column_text][vc_empty_space height=“100px“][\/vc_column][\/vc_row][vc_row css_animation=““ row_type=“row“ use_row_as_full_screen_section=“no“ type=“full_width“ angled_section=“no“ text_align=“left“ background_image_as_pattern=“without_pattern“ z_index=““][vc_column][vc_column_text]<\/p>\n

Lass uns sprechen<\/h2>\n

[\/vc_column_text][vc_empty_space height=“15px“][vc_column_text css=““]Die meisten Organisationen erkennen dieses Muster erst, wenn auch die dritte oder vierte Methode auf die gleiche Weise im Sande verl\u00e4uft. Wenn du wissen m\u00f6chtest, ob dein Team gerade an einem roten oder einem blauen Problem arbeitet, und welches Werkzeug oder welche Methode tats\u00e4chlich passt, lohnt sich ein Gespr\u00e4ch. <\/p>\n

In einem ersten Gespr\u00e4ch schaue ich mir gemeinsam mit dir an, wo in deiner Organisation die eigentlichen Hebel liegen. Kostenfrei und ohne Verpflichtung.[\/vc_column_text][vc_empty_space height=“50px“]\n

\n

<\/p>

    <\/ul><\/div>\n
    \n
    \n<\/fieldset>\n
    \n\t
    \n\t\t
    \n\t\t\t

    <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t<\/div>\n\t

    \n\t\t
    \n\t\t\t

    <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t<\/div>\n<\/div>\n

    \n\t
    \n\t\t
    \n\t\t\t

    <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t<\/div>\n\t

    \n\t\t
    \n\t\t\t