Quando / perché è più facile chiedere perdono che chiedere l'autorizzazione? [chiuso]

Il detto "È più facile chiedere perdono che chiedere l'autorizzazione" sembra piuttosto popolare tra i programmatori e IIRC è stato attribuito a Grace Hopper. In quali situazioni questo è in genere vero e perché credi che una simile proposizione controintuitiva sarebbe valida?

Penso che una ragione importante sia la responsabilità. Chiedendo il permesso, trasferisci la responsabilità alla persona che stai chiedendo, quindi quella persona potrebbe essere incline a negare solo per evitare di essere ritenuta responsabile del risultato, in caso di fallimento.

D'altra parte, una volta fatto, non è più un problema. Anche se il risultato è stato un fallimento, è comunque una tua responsabilità, non importa se ricevi il perdono o no.

Perché una volta che qualcosa è fatto, purché non peggiori le cose, è spesso più facile lasciarlo fuori che eliminarlo (cioè "ciò che è fatto è fatto").

È politica, tutta politica.

L'ho visto diventare una realtà in alcune occasioni, quando il management o il cliente hanno posto troppe barriere ai semplici cambiamenti (ad es. Recensioni di "qualità" da parte di persone che non sanno nulla del sistema, che hanno bisogno di ottenere l'approvazione da troppe aree di business) che a volte è più veloce e più semplice "strappare la benda": non dirlo a troppe persone, fai solo il cambiamento e, se funziona, tutti sono felici, potresti avere uno schiaffo al polso per "non seguire il processo" , eccetera.

Naturalmente, se la modifica fallisce, potresti trovare ancora più processi su cui si sovrappone ... ma questo è il rischio che hai preso.

(dichiarazione di non responsabilità: non ho problemi con i controlli di qualità, i controlli e i saldi, purché siano ragionevoli)

Penso che sia molto più complicato che tu pensi. Ecco le mie due opinioni sul problema:

Chiedere nulla costa

Sono sempre fantastico quando sento discussioni sull'aumento di stipendio. Le persone lamentano di non essere aumentate. Ma se non chiedono (a meno che non si trovino in una amministrazione con aumento automatico e predefinito dello stipendio), non otterranno nulla semplicemente aspettando.

È lo stesso con la macchina del vicino che vuoi prendere in prestito ... Potresti pensare "penserà che io sia ....." o "Non accetterà perché ....." o "Lui probabilmente ne avrà comunque bisogno .... ".

La verità è che non lo sai fino a quando non lo chiedi. Tuttavia, il modo in cui il nostro cervello lavora riempirà la nostra mente di pensieri inutili che hai creato te stesso. Nella maggior parte dei casi, sono falsi.

Quindi chiedere potrebbe essere la prima cosa da provare.

Farlo invece di chiedere ti impedirà di rifiutare. Se fallisci, puoi scusarti

Questa affermazione è vera anche perché nelle aziende in cui le responsabilità sono chiaramente definite e in cui le persone sono valutate in base ai risultati individuali.

Se chiedi al responsabile di un altro dipartimento qualcosa che può (pensava che crei) influenzarlo negativamente, ma il risultato (se positivo), non lo influenzerà, sicuramente rifiuterà, di essere al sicuro.

Due risposte sono molto simili: la paura. Nella prima risposta è la TUA paura, nella seconda è la paura di LORO.

Per superare la paura degli altri, non chiedere. In molti casi, ci riuscirai, e in caso di fallimento, allora sì ... scusarti sarà sufficiente.

Non nella maggior parte dei casi sfortunato, ma questo è un rischio che DEVI prendere per avanzare sia nella vita che nella tua carriera.

In un'organizzazione gerarchica in genere la direzione superiore non ha la minima idea dell'argomento su cui stai lavorando; quindi le loro decisioni sono, inevitabilmente, basate sul modo in cui rappresenti i tuoi suggerimenti. Rappresentare idee tecniche a persone non tecniche è notoriamente difficile: se lo spieghi così com'è, non capiscono nulla e potrebbero rifiutare proprio per questo. E se lo spieghi in modo che capiscano, non stai affermando la cosa così com'è. È anche etico, eh? Pertanto, potrebbe essere meglio fare la cosa giusta invece di cercare di spiegarlo in modo così fiorito e falso che il management è d'accordo con esso.

Non è irresponsabile. Anche se chiedessi l'autorizzazione, il risultato dipenderà fortemente da come hai rappresentato il problema. Dal momento che sei in grado di influenzare la decisione in questo modo, perché preoccuparsi? Fallo e rovina la burocrazia. Almeno non stai mentendo allora. Il punto chiave è che sai che è la cosa giusta da fare .

Certo, devi essere dannatamente sicuro di avere ragione, dato che ora sei tu a correre il rischio. Ciò che stai risparmiando è il tempo e l'impegno della tua direzione; non è una piccola impresa.

Quando chiedi il permesso, la persona che stai chiedendo deve immaginare le conseguenze che POTREBBE accadere se ti è permesso farlo. Ciò potrebbe includere cose terribili come la società in bancarotta. Una persona avversa al rischio (o una persona con una immaginazione volgare) ti dirà di no. Potrebbero non essere influenzati dal possibile beneficio del tuo piano. Quando vai avanti e lo fai senza chiedere, se ottieni il beneficio, è improbabile che tu sia punito o rimproverato. Se ottieni una piccola conseguenza, otterrai una piccola punizione. Naturalmente, se fallisci il tuo datore di lavoro, è tutto finito.

Non posso assumere qualcuno che abbia bisogno di controllare con me su ogni e-mail, ogni riga di codice, desiderando costantemente il permesso di svolgere il proprio lavoro regolare. Ma qualcuno che pensava fosse giusto rischiare l'intera compagnia in una scommessa ridicola (una società che non è la loro a rischio, dal momento che la possiedo non loro) non funzionerebbe ancora per me, anche se la scommessa ha dato i suoi frutti. Devi prendere parte a un'organizzazione abbastanza grande e profonda (ad esempio le forze armate statunitensi) per assumere questo atteggiamento - e devi capire molto bene i rischi.

Ciò che ho sperimentato a volte è difficile argomentare per apportare alcune modifiche al processo o agli strumenti di lavoro. Fintanto che il processo e gli strumenti attuali funzioneranno, potrebbe non esserci un forte incentivo per qualsiasi manager (o colleghi) a correre e correre il rischio di provare qualcosa di nuovo che a) potrebbe non essere effettivamente migliore oppure b) potrebbe fallire.

C'è tempo e risorse da dedicare, le persone potrebbero dover adattarsi, ecc. Se vai in anticipo e chiedi di fare un cambiamento, potresti incontrare un po 'di riluttanza e dovrai fare forti argomentazioni. Ci possono essere molte ragioni per cui un manager non vuole fare un cambiamento e non è necessariamente perché sono pigri o non sono in grado di cambiare. Ma stai chiedendo una decisione definitiva o un "Go!" che in realtà mette la responsabilità sul tuo manager.

Se apporti la modifica e la introduci nel tuo posto di lavoro nel momento in cui la modifica diventa evidente per i responsabili delle decisioni, potresti aver già dimostrato che:

a) Si può fare.
b) Funziona.
c) Migliora il tuo lavoro.
d) In realtà non ha richiesto molte risorse.

... e così via.

Se fallisse, potrebbero esserci delle ripercussioni, ma a meno che tu non stia lavorando con un boss schifoso, queste potrebbero non andare dietro a qualche schiaffo da polso e ad alcune umili scuse che vengono da te.

Lo abbiamo fatto una volta in cui abbiamo cercato di intrufolarci in un diverso sistema di tracciamento dei bug dietro la schiena del CTO. Quello sul posto era odiato con passione semplicemente da tutti i membri del team di sviluppo (ma era stato valutato - non da alcuno sviluppatore - e pagato, quindi ci si aspettava che lo usassimo) e ci rimanevano alcune licenze per un altro .

Purtroppo, questo esempio di chiedere perdono piuttosto che permesso è fallito. Ci è stato chiesto di tornare al vecchio sistema. Non so se qualcuno abbia davvero dovuto rispondere al CTO.

Quindi sostanzialmente, chiedendo al CTO di cambiare il sistema di tracciamento dei bug e ottenere l'autorizzazione: zero possibilità.

D'altra parte, iniziare a usarlo (senza spese diverse dal tempo impiegato per installarlo) e quindi vedere se potessimo ottenere un permesso DOPO il fatto: non una grossa possibilità, ma notevolmente superiore a zero.

Sembra che abbia sentito / letto che la dichiarazione precede l'ammiraglio Hopper, ma non ricordo i dettagli. Sospetto che la fonte originale sia andata perduta nel tempo.

Ad ogni modo, il primo che ricordo di aver sentito "È più facile scusarsi che chiedere il permesso" è stato in un discorso tenuto dalla grande signora quando un college vicino stava aprendo un nuovo centro di calcolo nel 1985. La sua spiegazione era che gli ammiragli a cui aveva riferito non lo avevano fatto di solito capisco cosa stava cercando di realizzare. La loro risposta predefinita a tutto ciò che non capivano era "No". Tuttavia, erano quasi sempre contenti dei risultati se ignorava la loro risposta. Quindi, ha rapidamente capito che era più semplice procedere senza chiedere il permesso; se qualcuno era arrabbiato, poteva solo dire che le dispiaceva.

Il mio nanosecondo era un caro ricordo fino a quando non si perse in una mossa qualche anno fa. :-(

perché credi che una proposta così controintuitiva sarebbe valida?

È un punto di vista che sostiene l'assunzione di rischi. Da quel punto di vista, se non corri rischi, non stai testando l'acqua e non raggiungerai il tuo massimo potenziale.

Se accetti di imparare dai tuoi errori, allora puoi essere d'accordo con questo adagio. Potresti scoprire che i lividi che prendi non sono così male come hai immaginato e quando hai successo, ti ritrovi premiato in eccesso, perché "hai mostrato leadership".

Questo modello di pensiero rende il concetto intuitivo, se non la pratica.

• http://en.wikipedia.org/wiki/Risk
• http://en.wikipedia.org/wiki/Risk_aversion

In quali situazioni questo è in genere vero

Questo atteggiamento è molto utile per chi si trova in una nuova situazione lavorativa, ma ha una comprovata esperienza (assumendo una gestione competente). Questo è quando gli errori saranno spesso perdonati (assumendo il buon senso, le intenzioni e la logica), e il progresso sarà molto ricompensato.