如何更有效地与各级别员工沟通

　　LinkedInCEO韦纳推荐了一套系统，可以更有效地与各级别员工沟通。
　　几年以前，一位赫赫有名的消费者网络公司创始人暨首席执行官曾分享过这样的趣闻：有一家公司的产品团队花费了几个星期时间，加班加点地想要完成在一个至关重要的发布日如期推出产品的目标。
　　在对这种产品进行最终评测的过程中，这家公司的首席执行官不经意地说道，他原本希望该产品的一个关键设计元素以另一种颜色出现。说完以后，他自己并没把这句话当回事儿，而是继续进行评测了。
　　但在几个星期以后，这位首席执行官怒气冲冲地质问产品团队为何会错过发布日，后者作出的解释是，他们暂时搁置了所有工作，全力对这种产品进行重新设计，以便使其符合他的口味。对于这个回答，这位首席执行官作出的反应是：你们都做了什么啊？！
　　其结果就是，这位首席执行官的非正式观察被产品团队错误地解读为全员集合式的命令，从而导致这种产品被迫推迟发布。
　　尽管这只是极端的例子，但确实凸显出了一个重要的问题：你所处的职位越高，那么发生这种事情的可能性就越大。对于那些经验不足的管理者来说，由于他们尚未适应自己新获得的权威，因此这个问题可能会显得尤其尖锐；然而，即使是在那些从业时间很长的公司高管中，类似的情况也屡见不鲜，这是因为他们已经忘记了自己的职位会给整个公司投下多么长的影子。
　　在几年以前，一名直接向我汇报工作的下属让我认识到了这一点。虽然他和他的团队欢迎我提出的意见，但他注意到，很多时候我所认为的非此即彼的言论会带来一场极具破坏性的消防训练，让所有人都在突然之间变得忙个不停。直到那时，我才发现原来我的观点会被如此看重。
　　为了解决这个问题，确保我和这个团队在遇到与此类似的情况时能保持一致的步调，我们将我可能提供的任何反馈信息（无论是在对话中提供的信息，还是通过电子邮件提供的信息）划分成了三个类别：个人观点、强烈建议以及强制命令。
　　后来的实施结果证明，这套系统起到了很大的帮助作用，因此我一直沿用至今。在这套系统的帮助下，我得以更加有效地与公司各个级别的员工进行沟通，尤其是那些可能还不太熟悉我的反馈信息风格或频率的新员工。
　　1。个人观点
　　在我提供的反馈信息中，绝大多数都可归入个人观点这一类别中。基本上来说，这是一种主观的、带有轶事性质的观点；也就是说，公司员工应该将其视为来自于一名用户、客户或是团队成员的观点。在完成沟通以后，到底是否按照我所提出的这种建议来采取行动，完全由项目的负责人来作出决定。
　　当提供个人观点这一类别的反馈信息时，你的头衔和权力都不应被考虑在内。需要指出的是，想要做到一点可谓知易行难，原因是你可能需要花费一些时间才能让团队中的初级成员认识到，对于他们挑战一名高级上司所作指导的作法，你确实是并不在意。
　　鉴于团队本身会拥有自己的强烈信仰，而且团队成员会忙于很多具有更高优先性的工作，再加上对于你所提出的产品改变，他们才是更加了解具体规格和成本的人，因此你要做好你的建议会被他们所摒弃的准备。如果你所给出的确实只是个人观点，而同时你手下又拥有真正合适的人才，那么你的建议遭到抛弃其实是件好事。
　　2。强烈建议
　　比个人观点类别高一级的则是强烈建议。与前者相比，强烈建议的程度当然要更高一些，但仍旧并非由你告诉产品团队该做些什么。
　　通常情况下，当一名高管想要通过自身经验来向产品团队给出建议，但同时又希望给后者以冒险、犯错和磨练其才能的机会，并最终扩大公司内部决策程序的范畴时，可使用强烈建议这种类别的反馈信息。
　　想要以这种方式来成功地提供反馈信息，那么你就必须信任你所任命的负责人，赋予他们以最终发言权。与此同时，想要做到这一点还需要团队本身能保持开放的思路，并在必要的时候尊重你所作出的更好的判断。不管是哪种情况，都需要你自己或是产品团队控制住自己的自负情绪，作出最符合公司利益的决定。
　　如果说这样的要求听起来像是一种很难达成的平衡的话，那是因为事实确实如此。
　　3。强制命令
　　在有些时候，无可避免地会出现产品团队判断错误的情况，这种错误的判断可能会带来非常严重的后果，而此时你需要做的就是先发制人地阻止这种后果成为事实，这跟允许产品团队冒险、犯错并从错误中汲取经验教训是一样重要的。
　　打个比方，如果你想要教会别人知道醉驾到底有多么危险，那么你要做的不是等着他们去喝点酒然后坐上驾驶座，从而让他们从亲身体验中认识到醉驾的危险性。
　　作为一名管理者，你需要判定如果一个团队履行你不认同的一项决定，那么随之而来的风险将会有多么巨大。然后，你必须确保如果这种风险有可能会对个人、团队和或公司造成持续性的损害，那么你就应该采取合适的措施来干预其中，并在阻止这种风险以后对相关团队进行教育。
　　在确有必要时发布强制性的命令，能让公司避免犯下代价高昂的错误，这对公司来说是非常有利的。但是，如果过于频繁地发布强制命令，或是在没有正确理由可提供支持的情况下发布这种命令，那么这种表现就意味着你对团队缺乏信任，从而导致团队失去动力。在有可能的情况下，还是尽量避免采用这种类型的信息反馈方式为好。