Ne dirigez pas avec "Non" C'est la décision du Premier ministre et si vous semblez le faire, comme vous l'avez vu, il est assez simple de faire en sorte que vous soyez dirigé vers suivre les instructions. Ce que vous voulez, c'est que le PM décide "Non" après avoir entendu vos commentaires techniques.

Dans cet esprit, vous devez développer quelques bizarreries de conversation qui ne disent pas "non "mais amènent le Premier ministre à comprendre tous les problèmes avant de décider oui ou non. Dans ce cas, il n'y a rien de mal avec "mais" (qui porte un non implicite) si vous avez envie de l'utiliser.

Mais n'est-ce pas non compatible?

Mais cela n'échouera-t-il pas pour les utilisateurs dans le [cas limite]?

Je peux le faire, mais ce serait beaucoup moins de travail si nous attendions la sortie du nouveau framework

Je suis préoccupé de faire cela avec notre technologie actuelle. Je ne suis pas sûr que cela fonctionnera pour tous nos utilisateurs.

Je ne vous suggère pas d'être compliqué et manipulateur, en disant oui quand vous voulez dire non, ou même en prétendant que vous pensez que c'est génial mais il y a juste ce petit détail ... Allez-y et dites que vous avez des problèmes avec l'idée, mais ne soyez pas celui qui prend la décision même si c'est juste un accident de formulation qui vous rend semblent faire cela. Laissez la décision au décideur. Comme vous l'avez vu, lorsque vous dirigez avec la décision, vous n'arrivez parfois jamais à dire les raisons.

Lorsque vous dirigez avec les raisons, vous pouvez obtenir des réponses telles que

c'est dans ma tête, vous implémentez simplement ce que j'ai demandé et je m'inquiéterai pour les utilisateurs de [edge case].

au moment où vous aurez terminé, l'infrastructure sera mise à jour et il y aura pas de problème.

Ces personnes savent que c'est un programme de premier choix et si cela ne fonctionne pas pour elles, elles peuvent toujours utiliser les anciens éléments

Ou vous pourriez obtenir

Oh. Je n'y ai pas pensé. Merci. Avez-vous 30 minutes pour découvrir des alternatives qui peuvent encore nous donner ce dont nous avons besoin?

N'importe lequel d'entre eux est bien meilleur qu'un VP vous traitant d'insubordonné et vous disant de "faire ce qu'on vous dit" comme un enfant. N'est-ce pas?

1. Sachez ce que vous faites. Les gens sont pris plus au sérieux lorsqu'ils sont bien informés et ont la réputation de faire avancer les choses.

2. Posez des questions. Si vous ne comprenez vraiment pas pourquoi quelque chose vous est demandé, dites-le. Les bons gestionnaires comprennent qu'ils obtiennent un meilleur travail de leurs employés lorsqu'ils savent pourquoi ils le font, et apprécient les commentaires de leurs subordonnés lorsqu'ils sont pertinents pour le problème en question.

3. Écoutez. Assurez-vous que vous comprenez ce qui est demandé et quelles sont les considérations.

4. Offrez du respect. Il est le manager, donc finalement ce qu'il dit va, mais si votre relation avec lui est respectueuse, votre opinion aura plus de poids .

5. Tenez compte du fait que Tout le monde passe de mauvais jours.

Commencer comme une seule équipe

D'abord et avant tout - supposons que tout le monde a le même objectif final - créer un excellent produit qui répond aux besoins des utilisateurs / clients, et le faire aussi efficacement que possible. Le défi est que différents points de vue interpréteront différemment l'état actuel et les prochaines étapes vers cet objectif. Le "must have" d'une personne peut être "impossible" pour une autre lorsque la connaissance de chacun est très différente. Une bonne équipe réunira différents points de vue et différentes expertises en la matière, le défi consistera à aligner les points de vue au point où de bonnes décisions peuvent être prises.

Ne donnez pas une négation générale dans le domaine de l'autre gars

Il dit "nous avons besoin de ça". En tant que PM, c'est son travail - savoir ce dont le client peut avoir besoin. Dire "non, nous n'avons pas besoin de cela" sans essentiellement faire PLUS de recherches qu'il a faites sera une bataille perdue. Et si (en tant qu'ingénieur) vous avez fait plus de recherches que lui, alors vous avez probablement mal réparti votre temps.

Argumenter depuis votre domaine

La zone de sécurité pour l'ingénierie est généralement "la solution que vous proposez est d'une difficulté inacceptable", et "les actions que vous proposez ne produiront pas les résultats que vous souhaitez". Le PM possède le domaine du problème (quel est le problème que votre produit résout?), L'ingénierie possède le domaine de la solution (comment le résolvons-nous?). Parce que vous possédez le domaine de la solution, il est plus facile d'argumenter du point de vue: - du temps nécessaire pour faire la solution décrite - de la réaction des changements potentiels à la solution à travers le système

L'astuce est que vous pouvez ' t dire "ce problème ne vaut pas la peine d'être résolu". La manière la plus sûre est que "ce problème prendra un temps inacceptable à résoudre - à savoir X ans". Avec cela sur la table, cependant, si vous dites "15 hommes-années" et que le PM va au VP, le VP est tout à fait en son pouvoir de dire "oui, je vais faire l'investissement - s'il vous plaît passer 15 années-hommes de mon de l'argent en faisant cette solution aussi vite que possible ... "

La stratégie encore meilleure consiste à avoir un plan en tête qui atteint l'objectif, mais d'une manière plus efficace. Par exemple, si vous êtes préoccupé par un cas de bord, que se passe-t-il si vous empêchez l'interface graphique d'autoriser le cas? Ou vous proposez un autre chemin? Souvent, j'ai pu obtenir une solution à 90% qui était acceptable et remarquablement moins chère que la proposition originale.

Connaissez votre auditeur

Chaque personne est différente - différentes personnes traiteront avec une négation à plat différemment. Différentes personnes auront besoin de différents niveaux de preuve ou de détails avant d'accepter. Certaines personnes ont besoin d'entendre l'idée, de réfléchir un peu et de vous revenir plus tard. Certaines personnes veulent avoir une image ou entendre une idée difficile par écrit, plutôt que d'essayer de l'attraper pendant qu'un orateur parle.

Sachez à qui vous parlez et construisez un modèle sur la façon dont ils réagissent généralement dans ces situations. Structurez la communication de manière à ce qu'elle soit dans le meilleur état possible pour l'acceptation, en particulier lorsque vous avez une idée vraiment difficile à vendre. Ceci est en partie le travail actif de construction de la confiance, et en partie le travail d'essais et d'erreurs.

Connaître l'ensemble du public

Soyez conscient de la dynamique du pouvoir . Ne pas être d'accord lors d'une réunion avec une partie prenante clé qui surclasse le PM n'est pas un bon endroit pour résoudre un problème. De préférence le plus petit public d'individus touchés. Bien que dans un cas particulièrement difficile, vous voudrez peut-être donner suite à votre nouvel accord trouvé en envoyant un e-mail à un public plus large disant "Je suis si heureux que nous soyons d'accord sur X, je voulais juste envoyer un courrier pour informer tout le monde! Merci de votre aide avec ça! "

De cette façon, c'est agréable, clair et documenté. :)

Background

Ma question générale est la suivante: comment puis-je émettre des réserves techniques sans contrarier les gens ou être trop hostile?

La première étape consiste à reconnaître les gens vous avez une perception différente de vous. C'est essentiel, car vous répondez «est-ce que cela a du sens» est une question triviale et vaut une réponse triviale. Mais la perception que les gens ont de tout peut être radicalement différente

Deuxièmement, pour la personne qui pose la question, elle n'a nulle part près de l'arrière-plan que vous connaissez ni de la compréhension technique et, dans de nombreux cas, peut manquer d'expérience technique pour raconter .

Ce que vous devez faire à l'avenir est ce qui suit:

• Supposez que la personne que vous «refusez» n'a aucune idée de la raison pour laquelle vous refusez quelque chose ou repousser. Toujours fournir une certaine "demande de clarification" lorsque vous refusez des choses et toujours fournir au minimum une raison.
• Pour les demandes plus complexes si vous avez à dire "non" incluez quelque chose comme "faites-moi savoir si vous souhaitez en discuter plus en détail, l'explication est relativement compliquée"

Les gens n'aiment pas du tout les réponses "non" lorsqu'ils proviennent d'une boîte noire. Celles-ci iront mal en général et sur le lieu de travail.

Une option consisterait à éviter de dire "Non" , même si vous dites "Non, parce que ..."

À la place dites "Oui, mais ..."

Quoi que votre responsable demande, dites " Oui, cela peut être fait, je peux certainement le faire ... MAIS cela demandera [plus de temps, plus de ressources, etc.] et aura les conséquences suivantes: [con list]. " L'avantage de cette méthode est qu'elle laisse la décision de faire / ne pas faire à votre responsable qui peut garder le contrôle.

Un avantage possible est que vous pourrez peut-être commencer par dire "Oui , Je peux le faire mais je vais d'abord devoir faire un peu de recherche ", puis je pourrai revenir plus tard avec une explication plus détaillée des conséquences.

Je suis surpris que presque toutes les autres réponses, tout en fournissant généralement de bons conseils sur "comment dire non", semblent ignorer le tableau général de "quel est le problème?".

Votre PM a un problème à résoudre. Quelqu'un - peut-être son manager, ou une autre équipe, ou un client ou un groupe de clients - compte sur lui pour une solution, et il compte à son tour sur vous pour une solution. Bien sûr une réponse «non» va le mettre sur la défensive, car au lieu de résoudre son problème, il crée simplement un problème supplémentaire (comment expliquer cela au patron / client / etc. sans se faire crier dessus, perdre son emploi ou simplement avoir l'air d'un idiot).

Peut-être qu'il a déjà pris une sorte d'engagement à ce sujet, ce qui, oui, est une mauvaise décision pour un manager de faire sans demander d'abord aux gens au courant, mais cela arrive, parfois involontairement.

Peu importe la façon dont vous habillez le "non". Peu importe que vous le formuliez sous la forme d'une question, et peu importe votre calme et votre diplomatie à ce sujet. Ces choses aident à graisser les rouages ​​de votre relation en cours, mais elles n'aident pas à résoudre son problème!

En tant que "créateur", c'est votre travail, si vous devez vous opposer, pour suggérer des alternatives . Trouvez un moyen de résoudre le problème , même si ce n’est pas de la manière dont il s’était initialement attendu. D'après mon expérience, seuls les managers les plus têtus et les plus incompétents insisteront sur une solution spécifique sans justification même lorsqu'ils se sont vu proposer des alternatives raisonnables.

De loin l'exemple le plus courant de ce que nous vivons probablement tous presque tous les jours est la gestion du temps. On nous dit que nous avons X jours pour faire Y. Cela ne vous mènera invariablement nulle part pour dire simplement " Désolé, mais je ne peux pas faire Y en X jours, ce n'est tout simplement pas assez de temps. " Vous on vous dira probablement de "faire en sorte que cela se produise" ou de "trouver un moyen de le faire".

Donc, vous ne dites pas cela. Vous dites:

Je ne sais pas si nous pouvons faire tout de Y en X jours, mais j'ai une suggestion: si nous supposons A, B et C, nous pourrons peut-être en prendre quelques raccourcis dans Q, et reporter la partie Z à un peu plus tard, et je pense que nous pourrions gérer cela en X jours. Cela fonctionnerait-il?

Si votre problème n'est pas temporel, mais plutôt basé sur des contraintes techniques, il vous suffit de changer quelques mots. Par exemple, dans votre cas, il semble y avoir une dépendance à l'égard d'un autre travail ou d'un composant en cours de réalisation, alors remplacez "dans X jours" par "sans que le composant / la fonctionnalité X soit terminé en premier", et au lieu de le formuler comme une incapacité, énoncez-le comme un risque.

Si vous venez de vous en sortir et que vous n'avez pas eu le temps de penser à des alternatives, dites-le simplement:

Je ' J'aimerais un peu de temps pour enquêter sur cette demande / exigence. Je pense qu'il pourrait y avoir des complications, mais si vous pouvez m'expliquer un peu pourquoi vous avez besoin de cela maintenant, je suis convaincu que je peux avoir une solution tracée pour vous d'ici la fin de la journée.

Il est toujours possible que vous n'obteniez pas votre chemin et que vous soyez "forcé" d'aller de l'avant malgré vos objections, mais si vous avez discuté d'alternatives, il vous a probablement déjà expliqué pourquoi elles ne fonctionneront pas , ce qui signifie qu'il a vraiment raison, ou du moins que sa justification est aussi valable que la vôtre. En outre, il est important de limiter le temps de cette enquête et de s'engager à lui revenir, sinon il semblera simplement (et à juste titre) que vous vous éloignez.

Incidemment, cela fonctionne dans pratiquement toutes les négociations, et vous devriez vraiment considérer cela comme une sorte de négociation. Il est beaucoup plus difficile de négocier si vous n'êtes prêt à mettre sur la table qu'une seule question (comme, par exemple, une somme d'argent); cela rend la négociation contradictoire plutôt que constructive, deux personnes se disputant pour obtenir une plus grande part du gâteau.

Vous voulez agrandir la tarte en proposant d'autres options ou concessions qui sont de préférence bon marché pour vous mais qui leur sont précieuses. Dans une négociation financière, il peut s'agir de plans de paiement, de taux d'intérêt, de cadeaux gratuits, de témoignages, ce genre de choses. Sur le lieu de travail, la devise principale est généralement l'effort, mais vous pouvez également négocier la portée, le temps, la qualité et une poignée d'autres modificateurs spécifiques au domaine (par exemple, les performances et la disponibilité dans le travail informatique).

Peut-être là est quelque chose de vraiment simple que vous pouvez faire en peu de temps et qui produira presque le même résultat ou du moins éliminera la plupart des risques qui vous préoccupent. Peut-être pas, mais donnez-vous au moins l'occasion d'y réfléchir avant de simplement dire «non» (sous quelque forme que ce soit).

Si vous êtes enclin à dire "non", vous devez avoir de bonnes raisons. Présentez ces raisons (prix, risque, temps, etc.) de manière à ce que toute personne raisonnable parvienne à la même conclusion que vous.

Vous êtes l'expert technique; si la solution proposée semble bonne pour le PM mais mauvaise pour vous, vous devriez être capable d'articuler les points pertinents dont le PM n'est peut-être pas au courant.

Présentez votre protestation aussi poliment que possible ... puis faites ce que votre manager vous dit après, quel que soit le résultat.

Je fais écho au sentiment que vous devriez toujours donner une explication, plutôt qu'un refus, car entendre «non» peut immédiatement donner un avantage à votre ton. Mais si vous avez déjà expliqué pourquoi l'idée est mauvaise et que votre patron insiste toujours pour qu'elle passe ... alors vous avez fait tout ce que vous pouvez.

Parfois, la poussée ne vient pas de votre patron, mais d'une source supérieure ou extérieure - j'ai déjà traité de cela. Les utilisateurs peuvent parfois faire des demandes déraisonnables dont ils ne peuvent pas être influencés, et malheureusement, c'est à votre patron de faire en sorte que cela se produise, et donc à vous de l'aider à y parvenir.

Maintenant, si c'est vraiment impossible, alors vous êtes vraiment dans une situation difficile et vous devrez peut-être vous asseoir avec votre patron et son patron pour expliquer que vous ne pouvez littéralement pas faire ce qu'ils demandent. Et vous devrez préciser que c'est impossible, car ils peuvent avoir l'impression que vous le dites simplement pour quitter le travail. Écrivez votre raisonnement, expliquez-le le plus clairement possible sans prendre un ton conflictuel et exprimez surtout le regret de ne pas pouvoir le faire, car j'espère que vous seriez disposé à le faire si cela était possible.

Vous demandez: "Comment puis-je émettre des réserves techniques sans contrarier les gens ou être trop hostile?". Il y a deux parties à cela:

1. En supposant que vous n'êtes pas hostile ou hostile, comment vous assurez-vous de refléter cela dans votre approche et comment vous exprimez les choses. Je pense que vous avez obtenu d'excellentes réponses sous cet angle.

2. Y a-t-il une base dans votre attitude, dans votre approche de votre travail et vos interactions professionnelles, qui peut apparaître comme antagoniste ou hostile quelle que soit la façon dont vous formulez les choses?

(De toute évidence, il vaut mieux dans les deux cas de bien formuler les choses plutôt que mal. Simplement bien formuler les choses n'est pas la solution à long terme.)

J'ai écrit et réécrit cette réponse et il est vraiment difficile de bien la communiquer. Je pense principalement à moi-même au début de ma carrière et à certains des problèmes que j'ai eu - dont certains que j'ai vaguement perçus à l'époque mais que je peux maintenant voir plus clairement avec le recul.

Par exemple, J'avais (et j'ai encore dans une large mesure) une vision assez scientifique de la manière dont vous proposez la meilleure mise en œuvre: le choc vigoureux de diverses propositions et la meilleure idée l'emporte. Aussi sincère que soit ma conviction, et aussi disposée que je l'étais à admettre que l'idée de quelqu'un d'autre était la meilleure idée, ce n'est pas ainsi que cela se présente à la plupart des gens. Et je peux voir maintenant que cette approche est étroite et ne regarde pas la vue d'ensemble d'une équipe, d'un projet et ce qu'est le succès.

Ma question est donc la suivante: quelle était votre attitude? Avez-vous considéré le PM comme un peu déconnecté des aspects techniques, et donc une voix moins valable dans la mise en œuvre? Étiez-vous en train d'explorer les options ou vouliez-vous persuader le Premier ministre que son idée était une mauvaise idée? Saviez-vous que le PM doit faire face à une série de questions et de pressions que vous n'avez pas, et qu'en fin de compte, le succès et l'utilité d'un projet ne se mesurent pas uniquement sur ses mérites techniques ou sa puissance? Étiez-vous en train de voir cela, presque inconsciemment, comme un rapide moment de «combat» où vous rassembliez votre argument, il affrontait le sien et la meilleure idée l'emporte? Étiez-vous inconsciemment en train de considérer le PM comme techniquement inférieur et donc comme celui qui doit venir vers vous (le techniquement supérieur) pour approbation ou validation de leur fonctionnalité suggestions?

I peut voir tous ces problèmes dans ma carrière. Rien de cynique: j'étais sincère et j'avais l'impression de contribuer du mieux que je pouvais en tant que membre de l'équipe. L'essentiel est que l'attitude mène à l'approche, qui mène au phrasé, et même alors l'attitude se répand dans les émotions et le langage corporel.

Peut-être que cette partie ne peut être apprise que «le difficile chemin "à travers l'expérience. Bien que certaines personnes semblent l'avoir appris à un âge beaucoup plus jeune que moi.

Je trouve que dans ces situations, il est utile d'être vraiment concret sur les résultats. Si vous spécifiez que de mauvaises choses vont arriver, alors leur spéculation (qu'ils gagneront plus d'argent) gagnera.

BTW, cela fonctionne aussi dans l'autre sens, quand vous voyez une opportunité mais tout voir c'est le risque.

Le sortir du domaine spéculatif et le mettre dans le concret fonde vraiment la conversation. Si vous pouvez dire: "20% de nos clients actifs ne pourront pas se connecter au produit", alors tout d'un coup, il leur appartient de résoudre cette réalité, et beaucoup de fois, la réalité est tout simplement trop intimidante.

Mais vous devez être préparé à la possibilité qu'ils aient raison. Parfois, la différence se résume à l'optimisme contre le pessimisme, et dans ce cas, la flexibilité est importante.