mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
Merge pull request #11042 from MarineFish/MarineFish-patch-1
A 3-step process for making more transparent decisions
This commit is contained in:
Xingyu.Wang
GitHub
commit
84d65851dc
@ -1,83 +0,0 @@
|
||||
MarineFish translating
|
||||
|
||||
A 3-step process for making more transparent decisions
|
||||
======
|
||||
|
||||
|
||||
One of the most powerful ways to make your work as a leader more transparent is to take an existing process, open it up for feedback from your team, and then change the process to account for this feedback. The following exercise makes transparency more tangible, and it helps develop the "muscle memory" needed for continually evaluating and adjusting your work with transparency in mind.
|
||||
|
||||
I would argue that you can undertake this activity this with any process--even processes that might seem "off limits," like the promotion or salary adjustment processes. But if that's too big for a first bite, then you might consider beginning with a less sensitive process, such as the travel approval process or your system for searching for candidates to fill open positions on your team. (I've done this with our hiring process and promotion processes, for example.)
|
||||
|
||||
Opening up processes and making them more transparent builds your credibility and enhances trust with team members. It forces you to "walk the transparency walk" in ways that might challenge your assumptions or comfort level. Working this way does create additional work, particularly at the beginning of the process--but, ultimately, this works well for holding managers (like me) accountable to team members, and it creates more consistency.
|
||||
|
||||
### Phase 1: Pick a process
|
||||
|
||||
**Step 1.** Think of a common or routine process your team uses, but one that is not generally open for scrutiny. Some examples might include:
|
||||
|
||||
* Hiring: How are job descriptions created, interview teams selected, candidates screened and final hiring decisions made?
|
||||
* Planning: How are your team or organizational goals determined for the year or quarter?
|
||||
* Promotions: How do you select candidates for promotion, consider them, and decide who gets promoted?
|
||||
* Manager performance appraisals: Who receives the opportunity to provide feedback on manager performance, and how are they able to do it?
|
||||
* Travel: How is the travel budget apportioned, and how do you make decisions about whether to approval travel (or whether to nominate someone for travel)?
|
||||
|
||||
|
||||
|
||||
One of the above examples may resonate with you, or you may identify something else that you feel is more appropriate. Perhaps you've received questions about a particular process, or you find yourself explaining the rationale for a particular kind of decision frequently. Choose something that you are able to control or influence--and something you believe your constituents care about.
|
||||
|
||||
**Step 2.** Now answer the following questions about the process:
|
||||
|
||||
* Is the process currently documented in a place that all constituents know about and can access? If not, go ahead and create that documentation now (it doesn't have to be too detailed; just explain the different steps of the process and how it works). You may find that the process isn't clear or consistent enough to document. In that case, document it the way you think it should work in the ideal case.
|
||||
* Does the completed process documentation explain how decisions are made at various points? For example, in a travel approval process, does it explain how a decision to approve or deny a request is made?
|
||||
* What are the inputs of the process? For example, when determining departmental goals for the year, what data is used for key performance indicators? Whose feedback is sought and incorporated? Who has the opportunity to review or "sign off"?
|
||||
* What assumptions does this process make? For example, in promotion decisions, do you assume that all candidates for promotion will be put forward by their managers at the appropriate time?
|
||||
* What are the outputs of the process? For example, in assessing the performance of the managers, is the result shared with the manager being evaluated? Are any aspects of the review shared more broadly with the manager's direct reports (areas for improvement, for example)?
|
||||
|
||||
|
||||
|
||||
Avoid making judgements when answering the above questions. If the process doesn't clearly explain how a decision is made, that might be fine. The questions are simply an opportunity to assess the current state.
|
||||
|
||||
Next, revise the documentation of the process until you are satisfied that it adequately explains the process and anticipates the potential questions.
|
||||
|
||||
### Phase 2: Gather feedback
|
||||
|
||||
The next phase involves sharing the process with your constituents and asking for feedback. Sharing is easier said than done.
|
||||
|
||||
**Step 1.** Encourage people to provide feedback. Consider a variety of mechanisms for doing this:
|
||||
|
||||
* Post the process somewhere people can find it internally and note where they can make comments or provide feedback. A Google document works great with the ability to comment on specific text or suggest changes directly in the text.
|
||||
* Share the process document via email, inviting feedback
|
||||
* Mention the process document and ask for feedback during team meetings or one-on-one conversations
|
||||
* Give people a time window within which to provide feedback, and send periodic reminders during that window.
|
||||
|
||||
|
||||
|
||||
If you don't get much feedback, don't assume that silence is equal to endorsement. Try asking people directly if they have any idea why feedback is not coming in. Are people too busy? Is the process not as important to people as you thought? Have you effectively articulated what you're asking for?
|
||||
|
||||
**Step 2.** Iterate. As you get feedback about the process, engage the team in revising and iterating on the process. Incorporate ideas and suggestions for improvement, and ask for confirmation that the intended feedback has been applied. If you don't agree with a suggestion, be open to the discussion and ask yourself why you don't agree and what the merits are of one method versus another.
|
||||
|
||||
Setting a timebox for collecting feedback and iterating is helpful to move things forward. Once feedback has been collected and reviewed, discussed and applied, post the final process for the team to review.
|
||||
|
||||
### Phase 3: Implement
|
||||
|
||||
Implementing a process is often the hardest phase of the initiative. But if you've taken account of feedback when revising your process, people should already been anticipating it and will likely be more supportive. The documentation you have from the iterative process above is a great tool to keep you accountable on the implementation.
|
||||
|
||||
**Step 1.** Review requirements for implementation. Many processes that can benefit from increased transparency simply require doing things a little differently, but you do want to review whether you need any other support (tooling, for example).
|
||||
|
||||
**Step 2.** Set a timeline for implementation. Review the timeline with constituents so they know what to expect. If the new process requires a process change for others, be sure to provide enough time for people to adapt to the new behavior, and provide communication and reminders.
|
||||
|
||||
**Step 3.** Follow up. After using the process for 3-6 months, check in with your constituents to see how it's going. Is the new process more transparent? More effective? More predictable? Do you have any lessons learned that could be used to improve the process further?
|
||||
|
||||
### About The Author
|
||||
Sam Knuth;I Have The Privilege To Lead The Customer Content Services Team At Red Hat;Which Produces All Of The Documentation We Provide For Our Customers. Our Goal Is To Provide Customers With The Insights They Need To Be Successful With Open Source Technology In The Enterprise. Connect With Me On Twitter
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/open-organization/17/9/exercise-in-transparent-decisions
|
||||
|
||||
作者：[a][Sam Knuth]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/samfw
|
||||
@ -0,0 +1,80 @@
|
||||
A 3-step process for making more transparent decisions
|
||||
======
|
||||
|
||||
|
||||
要让你的领导工作更加透明，其中一个最有效的方法就是将一个现有的程序开放给你的团队进行反馈，然后根据反馈去改变程序。下面这些练习能让透明度更佳切实，并且它有助于开发“肌肉记忆”，此二者可以持续评估且调整你的工作。
|
||||
|
||||
我想说，你可以通过任何程序来完成这项工作—即使是那些“范围外的”的程序，像是晋升或者自行调整程序。但是如果第一次它对于机内测试设备来说太大了，那么你可能需要从一个不那么程序的方法开始，比如旅行批准程序或者你的寻找团队空缺候选人的系统。（举个例子，我使用了在我们的招聘和晋升程序）
|
||||
|
||||
开放程序并使其更佳透明可以建立你的信誉并增强团队成员对你的信任。它会迫使你以一种可能超乎你设想和舒适程度的方式 “走透明的路”。以这种方式工作确实会产生额外的工作，尤其是在过程的开始阶段——但是，最终这种方法对于让管理者（比如我）对团队成员很有效的负责，而且它会更加相容。
|
||||
|
||||
### 阶段一：选择一个程序
|
||||
|
||||
**第一步.** 想想你的团队使用的一个普通的或常规的程序，但是这个程序通常不需要仔细检查。下面有一些例子:
|
||||
|
||||
* 招聘：如何创建职位描述、如何挑选面试团队、如何筛选候选人以及如何做出最终的招聘决定。
|
||||
* 规划：你的团队或组织如何确定目标年度或季度。
|
||||
* 升职：你如何选择并考虑升职候选人,并决定谁升职。
|
||||
* 经理绩效评估：谁有机会就经理绩效提供反馈，以及他们是如何反馈。
|
||||
* 旅游：旅游预算如何分配,以及你如何决定是否批准旅行（或提名某人是否旅行）。
|
||||
|
||||
|
||||
|
||||
上面的某个例子可能会引起你的共鸣，或者你可能会发现一些你觉得更合适的东西。也许你已经收到了关于某个特定程序的问题，又或者你发现自己屡次解释某个特定决策的基本原理。选择一些你能够控制或影响的东西——一些你相信你的成员关心的东西。
|
||||
|
||||
**第二步.** 现在回答以下关于这个程序的问题：
|
||||
|
||||
* 该程序目前是否记录在一个所有成员都知道并可以访问的地方？如果没有，现在就开始创建文档(不必太详细;只需要解释这个程序的不同步骤以及它是如何工作的)。你可能会发现这个过程不够清晰或一致，无法进行文档记录。在这种情况下，用你认为理想情况下应该使用的方式去记录它。
|
||||
* 完成程序的文档是否说明了在不同的点上是如何做出决定？例如，在旅行批准程序中，它是否解释了如何批准或拒绝请求。
|
||||
* 程序的输入是什么？例如，在确定部门年度目标时，哪些数据用于关键绩效指标，查找或者采纳谁的反馈，谁有机会回顾或“停止活动”。
|
||||
* 这个过程会做出什么假设？例如，在升职决策中，你是否认为所有的晋升候选人都会在适当的时间被他们的经理提出。
|
||||
* 程序的输出是什么？例如，在评估经理的绩效时，评估的结果是否会与经理共享，任何审查的方面是否会与经理的直接报告(例如，改进的领域)更广泛地共享？
|
||||
|
||||
|
||||
|
||||
回答上述问题时，避免作出判断。如果这个程序不能清楚地解释一个决定是如何做出的，那也可以接受。这些问题只是评估现状的一个机会。
|
||||
|
||||
接下来,修改程序的文档,直到你对它充分说明了程序并预测潜在的问题感到满意。
|
||||
|
||||
### 阶段二:收集反馈
|
||||
|
||||
下一个阶段牵涉与你的成员分享这个程序并要求反馈。分享说起来容易做起来难。
|
||||
|
||||
**第一步.** 鼓励人们提供反馈。考虑一下实现此目的的各种机制：
|
||||
|
||||
* 把这个程序公布在人们可以在内部找到的地方，并注意他们可以在哪里发表评论或提供反馈。谷歌文档可以很好地评论特定的文本或直接建议文本中的更改。
|
||||
* 通过电子邮件分享过程文档，邀请反馈。
|
||||
* 提及程序文档，在团队会议或一对一的谈话时要求反馈。
|
||||
* 给人们一个他们可以提供反馈的时间窗口，并在此窗口定期发送提醒。
|
||||
|
||||
|
||||
|
||||
如果你得不到太多的反馈，不要认为沉默就等于认可。你可以试着直接询问人们，他们为什么没有反馈。是因为他们太忙了吗？这个过程对他们来说不像你想的那么重要吗？你清楚地表达了你的要求吗？
|
||||
|
||||
**第二步.** 迭代。当你获得关于程序的反馈时，请让团队对流程进行修改和迭代。加入改进的想法和建议，并要求确认预期的反馈已经被应用。如果你不同意某个建议，那就接受讨论，问问自己为什么不同意，以及一种方法和另一种方法的优点是什么。
|
||||
设置一个收集反馈和迭代的时间盒有助于向前推进。一旦反馈被收集和审查，你应当讨论和应用它，并且发布最终的程序供团队审查。
|
||||
|
||||
### 阶段三：实现
|
||||
|
||||
实现程序通常是计划中最困难的阶段。但如果你在修改过程中考虑了反馈意见，人们应该已经预料到了，并且可能会更支持你。从上面迭代过程中获得的文档是一个很好的工具，可以让你对实现负责。
|
||||
|
||||
**第一步.** 审查实施需求。许多可以从提高透明度中获益的程序只需要做一点不同的事情，但是你确实需要检查你是否需要其他支持（例如工具）。
|
||||
|
||||
**第二步.** 设置实现的时间表。与成员一起回顾时间表，这样他们就知道会发生什么。如果新程序需要对其他程序进行更改，请确保为人们提供足够的时间去适应新性能，并提供沟通和提醒。
|
||||
|
||||
**第三步.** 跟进。在使用程序3-6个月后，与你的成员联系，看看进展如何。新流程是否更加透明，更有效，更可预测？你有什么经验教训可以用来进一步改进这个程序吗？
|
||||
|
||||
### 关于作者
|
||||
Sam Knuth；我有幸在 Red Hat 领导客户内容服务团队；我们提供给我们的客户所有产生的文档。我们的目标是为客户提供他们在企业中使用开源技术取得成功所需要的洞察力。在Twitter上与我联系
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/open-organization/17/9/exercise-in-transparent-decisions
|
||||
|
||||
作者：[a][Sam Knuth]
|
||||
译者：[MarineFish](https://github.com/MarineFish)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/samfw<!doctype html>
|
||||
Loading…
Reference in New Issue
Block a user