Employee Handbook: Chapter 2

This article contains AI-generated translation.

 Author
 Previous

引言：前几天，网上有流传出米哈游员工手册的高糊截图，因为对内容实在感兴趣，我就保存了下来。最近两天顶着接近马赛克的画质读完可读的部分，几乎泪流满面，对其中的内容深感触动。由于其中的文字内容实在过于模糊，以至于OCR都难以识别，于是决定将其中的内容手打转换为文本，打算长久保存用以激励自己。
Introduction: A few days ago, there were circulating low-quality screenshots of the miHoYo employee handbook online. Because I was interested in the content, I saved them. Over the past two days, despite the nearly mosaic-like image quality, I managed to read the readable parts and tears filled my eyes. I was deeply moved by the content. Since the text was extremely blurry, to the point where OCR (Optical Character Recognition) couldn't recognize it, I decided to manually transcribe the content into text, intending to save it for long-term inspiration.

## 02 I Am A Newbie, Boss

特别提醒：入职指引，请看另一本书哦
Special reminder: Onboarding instructions, please refer to another book.

剩下的，请翻开下一页，233
For the rest, please turn to the next page, lol.

老同学可以跳过看第三章咯
Old classmates can skip to Chapter 3.

### 2.1 Trembling on the First Morning

当第一天前台小姐姐把你带到工位的时候，或许你会看到，一群群人站着围成一圈在轮流说话。
When the front desk sister brings you to your workstation on the first day, you might see groups of people standing in circles, taking turns to speak.

Emmm……说明你已经错过第一天的早会了!
Emmm... it means you missed the morning meeting on the first day!

如1.2中所讲，我们是一个Team of Teams的组织形式。所以，每天早上，我们都会以Teams为单位进行早会。早会制度从miHoYo成立第一天，大概是2011年春天的某一天开始就存在了。作为miHoYo少有的要求严格执行的制度之一。早会对于日常工作有着十分重要的意义。
As mentioned in 1.2, we follow a Team of Teams organizational structure. Therefore, every morning, we have team-based morning meetings. The morning meeting system has been in place since the first day of miHoYo, around springtime in 2011. It is one of the few strictly enforced systems at miHoYo and holds significant importance in our daily work.

基于敏捷开发的原则，项目上的任务每天都在发生变化，出现各种问题。早会的重要意义在于，集合某一功能的相关人员，高效同步开发进展与问题，以达到目标同步，问题暴露，进度管理等目的。注意，早会只提出问道，不进行讨论解决问题！因为没那个时间。
Based on the principles of agile development, tasks on projects are changing every day, and various issues arise. The morning meeting is essential for gathering relevant team members, efficiently synchronizing development progress and issues, to achieve synchronization of goals, expose problems, and manage progress. Please note that the morning meeting only raises questions and does not engage in problem-solving discussions! There's simply no time for that.

特别说明，作为一项全员皆知的规定，任何小组成员，早会迟到要买水果。
A special note: As a well-known rule, any team member who arrives late to the morning meeting has to buy fruits.

### 2.2 How Should I Work?

在miHoYo，我们一直秉持着我们的团队理念，就是“跟优秀的人在一起，做出优秀的事情，获得优秀的回报”。那么在加入我们之后，应该如何去做优秀的事情?如上一节所讲，我们在努力构建一个扁平的自组织结构的组织，并努力尽一切可能保持内部信息的透明与流动。那么在这个背景下，每一个人该如何工作，如何思考决策。答案就是：
At miHoYo, we have always upheld our team philosophy: "Being with excellent people, doing excellent things, and getting excellent rewards." So, after joining us, how can you do excellent things? As mentioned in the previous section, we are striving to build a flat self-organizing structure and make every effort to maintain transparency and flow of internal information. In this context, how should each individual work and make decisions? The answer is:

Context, not Control！

Context, not Control的理念来源于Netflix。
The concept of "Context, not Control" originated from Netflix.

先解释一下字面意思：
Let's explain the literal meaning:

什么是Context?一切做决策需要的背景信息，都叫Context。比如：我们项目目标用户是啥，我们的历史数据如何，一测用户平成是咋样的反馈，做一个Feature的人力成本如何，技术风险的高低，甚至某个同学熬夜加班效率特别高23.等等这些都是Context
What is Context? It refers to all the background information needed to make decisions. For example: Who are our target users for the project? How is our historical data? What feedback did users provide in previous surveys? What is the manpower cost for implementing a feature? What is the level of technical risk? Is there a team member who is particularly efficient when working late into the night, etc. All these are Context.

那什么是Control呢? 一切流程化的执行手段，比如: OA审批流程，指令拆分分解，委员会投票表决等。
Then, what is Control? It refers to all the process-oriented execution methods, such as the OA approval process, task decomposition, committee voting, etc.

那对我的工作而言，这两者是啥区别？
So, what is the difference between Control and Context in my work?

“Control”的工作方式意味着，严格遵守你的上司给你下达的指令，不必去多想他为什么这么决策，只管执行好就行，也不用考虑这个指令之外的事情，只对下达的这个命令范畴内的事情来负责。如果需要其他人来配合那就拆分，然后分配任务出去，然后同样严格控制他们来执行。这种工作方式，在很多大型企业和组织，都是十分常见的。
"Control" means strictly following the instructions given by your supervisor, without needing to think too much about their decision-making process. Just focus on executing the instructions and only take responsibility for the tasks within the scope of the given command. If you need others to collaborate, you split the tasks, assign them, and strictly control their execution. This way of working is quite common in many large companies and organizations.

“Context”的工作方式则不一样。当进行一个任务的时候，我们首先需要全面的了解上下文的信息，基于自己对眼前工作的专业的认识，结与相关人员充分沟通同步认知，然后做出好的解决方案并执行完成。
The "Context" way of working is different. When working on a task, we first need to have a comprehensive understanding of the contextual information. Based on our professional knowledge and understanding of the current task, we communicate and synchronize with relevant team members to ensure a shared understanding. Then, we come up with good solutions and execute them.

举一个具体的例子，当我们要实现一个怪物的自动索敌跟踪功能的时候。
Let's take a specific example of implementing an automatic enemy tracking feature for a monster.

“Control”的故事会是这样：客户端主程和策划讨论完成后，基于他的知识与经验，告诉具体做Feature的程序A，用Unity的NavMeshAgent来创建Navmesh，然后实现一个寻路算法，来满足需求上的功能。
In the "Control" story: After discussing with the client's lead programmer and the game designer, based on their knowledge and experience, you tell the specific programmer (Programmer A) to use Unity's NavMeshAgent to create a Navmesh and implement a pathfinding algorithm to fulfill the required functionality.

Context的故事则是这样的:客户端组长拉具体的负责实现的程序A同学和策划进行深入讨论，告诉他要做一个这样的Feature，并建议可以用到NavMeshAgent这样的功能。
In the "Context" story: The team lead from the client's side invites Programmer A, who is responsible for implementing the feature, to have an in-depth discussion with the game designer. They explain the desired feature and suggest utilizing functions like NavMeshAgent.

看起来故事的开头并没有太大的差别，甚至很多时候这两个故事的结果也会差不多，程序A顺利使用NavMeshAgent实现了Feature，并通过了验收与测试。但是当我们的项目越来越大，越来越复杂的时候，这两条故事线的发展会天差地别。
At first glance, the beginnings of these two stories may not differ much, and often the end results might be similar as well. Programmer A successfully implements the feature using NavMeshAgent and passes the acceptance and testing. However, as our project grows larger and more complex, the development of these two storylines will diverge significantly.

Control线的，程序A看完了文档，看完了策划的需求文档，开始动手实现，一天后他实现了功能，在一个测试场景里跑了一下，发现没有太大问题，他喊策划来验收了一下，从而提出了修改意见，然后自己跑了跑也发现问题不大。这时候程序A认为再过一天修完Bug ，close掉这个feature毫无风险，第二天，修完bug后他把这个功能放到游戏大世界中去。这是一个面积一万倍于测试场景的世界，而且地形的复杂程度也比测试场景要高很多，不过地形复杂这件事早在程序的意料之中，他准备再花一整天时间来好好处理各种意料之外的情况。想到这里。他按下了NavMesh的Build按钮，起身准备去接一杯水，1分钟后程序A回到自己的工位，他发现这个还没有build，他敏捷的意识到出问题了，这个世界太tmd大了，光离线构建一个NavMesh就要好久，这可能会是个坑。程序啜了一口水，想了想，马上就要周版本打包了，这个任务还是得close。主程说了让我用这个方法，他应该心里有数吧，反正我毫无bug的把这个功能实现完了。策划也验收得差不多了，就这样先提交一版吧，程序A不知思考了几分钟，正等他回过神来的时候，NavMesh已经构建完了。在PC上这还是挺快的嘛，程序A继续开始做其他的功能与测试，并准时在打包前提交了全部代码。
In the Control scenario, Programmer A reads the documentation, understands the requirements from the game designer, and starts working on the implementation. After a day, they have implemented the functionality and tested it in a small test scene, finding no major issues. Programmer A calls the game designer for acceptance, provides some suggestions for modifications, and tests it again, finding no major problems. At this point, Programmer A believes that it's risk-free to spend another day fixing bugs and closing this feature. The next day, after fixing the bugs, Programmer A puts this functionality into the large game world. This world is a thousand times larger than the test scene and has much more complex terrain. However, Programmer A anticipated the complexity of the terrain and planned to spend another whole day dealing with various unforeseen situations. Thinking about this, Programmer A presses the NavMesh Build button and gets up to fetch a glass of water. One minute later, Programmer A returns to their workstation and realizes that the build hasn't completed yet. With a keen awareness, Programmer A senses that something has gone wrong. This world is too darn big, and it takes quite a while to build the NavMesh offline. It could be a pitfall. Programmer A takes a sip of water, thinks for a moment, realizing that the weekly version is about to be packaged, and decides to close this task. The lead programmer told me to use this method, so they should have a good understanding. Besides, I implemented this feature without any bugs. The game designer's acceptance is also almost complete. Let's submit a version like this for now. Programmer A contemplates for a few minutes. Just as they snap back to reality, the NavMesh build has finished. It's quite fast on the PC. Programmer A continues to work on other features and testing, and submits all the code before the packaging deadline.

几个小时后，当晚的周版本打包完成了，大家开始下载，不知为何今晚的下载速度有些慢大家又开始抱怨这个WiFi AP太卡了，都集中在同一时间下载。终于，十几分钟后，有人下载好了，开始回归Feature。“卧槽，怎么闪退了？”一个用iPhone 7的人喊到、“是啊，我这里好像也闪退了。”越来越多的人发现自己的设备无法正常进行游戏。简单统计后，大家发现，除了最高端设备，好像其他的都很容易闪退。经过了1个小时的排查后，大家发现，这周周版本的包比上一周整整大了500mb，而这其中95%都是内存爆炸，都是因为太多NavMesh的载入而导致的。当目光投向程序A的时候，他很坦然地承认了问题，确实看来不能这么做。然后他用比别人更专业，更精准的语言来描述了问题，以及在当前Solution下无解的程度。现在皮球回到了客户端主程的身上，在忙碌的周版本的午夜，他的疲惫显而易见的浮在脸上。因为屁股后面还排了好几个人在反馈问题。PM还在问他要不要重新打包好验收其他功能，给他用来思考这个问题的时间只有不到一分钟。那肯定是没办法离线缓存所有的NavMesh啊。这个世界太大了，是的，程序A附和道，然后他继续在等待新的指示。主程叹了一口气。在叹气的这蓄须臾之间他想了很多，今晚的下班时间应该又是3点以后了吧；这个寻路的功能这么做下去恐怕要重新设计了；恐怕没法三言两语就把后续的走路时间给讲清楚，他自己还需要去思考更多；还有，他还想到了这项目再这么做下去，简直就是个无底深渊……
A few hours later, the packaging of the weekly version was completed. Everyone started downloading it, but for some reason, the download speed was slow tonight. People began to complain about the slow Wi-Fi access point, as everyone was downloading at the same time. Finally, after about ten minutes, someone finished downloading and started testing the features. "Oh no, it crashed!" shouted someone using an iPhone 7. "Yeah, it seems to crash on my device too," more and more people discovered that their devices couldn't run the game properly. After a simple investigation, they found out that except for the high-end devices, most of the others were prone to crashing. After an hour of troubleshooting, they discovered that the package size of this week's version was 500mb larger than the previous week, and 95% of the increase was due to memory explosions caused by excessive NavMesh loading. When their attention turned to Programmer A, he admitted the problem honestly, acknowledging that it was indeed not a good approach. He then used more professional and precise language to describe the problem and the extent to which it was unsolvable under the current solution. Now the ball was in the hands of the client's lead programmer. In the busy midnight of the weekly version, his fatigue was evident on his face because several people were waiting behind him to report issues. The project manager was asking if he should package and accept other features, giving him less than a minute to think about this problem. It was impossible to offline cache all the NavMesh. "The world is too big," Programmer A agreed, and he continued to wait for new instructions. The lead programmer sighed. In that moment of sighing, he thought about many things. It was probably going to be past 3 am again when they finished work tonight. This pathfinding feature would probably need to be redesigned if they continued like this. He doubted he could explain the subsequent walking time in just a few words; he needed to think about it more himself. Moreover, he realized that if they continued this way, the project would be an endless abyss...

在另一条世界线上，Context线的故事，则完全不同，程序A还在会议室里跟策划讨论，这次的会议有点长，客户端组长已经忙别的去了。“这个功能，要用在哪？地下城？”“嗯，不止地下城，大世界也会有。”策划答道。嗯，地下城还好说，除了地形之外，其他跟崩三差不多，“那大世界是啥需求？怪可以随处跑吗？”“可以。”策划随口答道，这在他看来是跟其他毫无差别的需求，十分平常。而此时，程序A脸色沉了下来，见程序A没有爽快的接锅，策划同学眉头一皱，发现事情并不简单。“有什么问题吗？”他试探性低问道。“有，你确定世界这么大，怪的活动范围是不受限制的对吧？”程序A又确认了一遍。“是的，至少是可以被拉到很远的地方的。”策划回答道。“我先去了解一下NavMeshAgent的功能吧，现在还没法确定这个功能怎么做。”好吧，虽然PM要求的需求评审时间快到了，但此时好像也只能这样了。“那么有什么问题随时找我吧，如果有问题，我们也可以想想其他的解决方案”，策划说到。两人起身走到门口，策划突然停住了脚步，因为在他看来这个需求十分平常，不是所有游戏都是这样的吗？他觉得这个问题必须问清楚。于是他问道：“我们跟其他游戏在实现上有什么不同吗？”正在翻阅手机的程序A抬起头：“有很大的不同啊”，他放下手机，上面显示着NavMeshAgent的文档。他开始跟策划解释为什么有巨大的不同，平时少言寡语的程序A，像是打开了封印千年的话匣子，为什么要离线缓存多大的Mesh，如果Runtime计算会不会卡，异步Load我们可能要自己实践…，等程序A再次闭上嘴的时候，他自己觉得自己的脑中貌似已经有了一个大概的Solution了。策划一直听完了程序A的陈述，偶尔插一两个问题，虽然有些细节他不清楚，但大概意思是get到了。好歹我本科也是读CS的呢，策划自己心里盘算着。这场会议，终于在近两个小时的讨论后结束了。
In another timeline, in the story of the Context thread, things were completely different. Programmer A was still in the meeting room discussing with the game designers. This meeting was a bit long, and the lead of the client-side group had already left to attend to other tasks. "Where will this feature be used? In dungeons?" "Yes, not only in dungeons, but also in the open world," the game designer replied. "Well, dungeons are manageable. Besides the terrain, everything else is similar to the previous game. But what about the open world? Can monsters roam freely?" "Yes, they can," the game designer casually responded, considering it a common requirement similar to others. However, Programmer A's face darkened. Seeing that Programmer A didn't readily accept the task, the game designer frowned, realizing that things weren't as simple as they seemed. "Is there a problem?" he tentatively asked. "Yes, are you sure that in such a vast world, the range of monster activity is unrestricted?" Programmer A confirmed again. "Yes, at least they can be dragged to faraway places," the game designer replied. "Let me first understand the functionality of NavMeshAgent. We can't determine how to implement this feature yet." Well, even though the deadline for the requirement review requested by the project manager was approaching, it seemed like they had no choice but to proceed this way. "Feel free to come to me if you have any problems. We can also think about other solutions if needed," the game designer said. The two of them walked to the door, but the game designer suddenly stopped in his tracks. He felt that this requirement was very common. Aren't all games like this? He felt that this question needed to be clarified. So he asked, "Are there any differences in our implementation compared to other games?" Programmer A, who was looking at his phone, raised his head. "There are significant differences," he put down his phone, which displayed the documentation for NavMeshAgent. He began to explain to the game designer why there were significant differences. The usually taciturn Programmer A seemed like he had opened a Pandora's box of words, discussing why they needed to offline cache such large meshes, whether there would be performance issues with runtime calculations, and the possibility of asynchronous loading that they might need to experiment with... When Programmer A closed his mouth again, he himself felt that he had a rough idea of a solution in his mind. The game designer listened to Programmer A's explanation, occasionally interjecting with one or two questions. Although he was not familiar with some of the details, he understood the general idea. After all, I also studied computer science during my undergraduate studies, the game designer thought to himself. Finally, after nearly two hours of discussion, the meeting came to an end.

后来程序A了解完了NavMeshAgent的功能向程序组长表示，直接来用并不靠谱，但在长期的沟通中，他们都清楚这个Feature还是必须要做完，再后来他们又去找了工具组，引擎组，大家一起讨论了一个改造NavMeshAgent的方案，基于各方面的支持，先实现了一版功能。然后，又是几周的迭代和反馈测试，才最终把这个功能稳定下来。
Later, after Programmer A understood the functionality of NavMeshAgent, they expressed to the team leader of the programming group that using it directly was not reliable. However, through long-term communication, they both understood that completing this feature was still necessary. Subsequently, they approached the tooling group and the engine group, and together they discussed a plan to modify NavMeshAgent. With support from all sides, they implemented an initial version of the feature. Then, after several weeks of iteration and feedback testing, they finally stabilized this functionality.

Context线的故事讲完了，如果你问我为什么中间没有写，策划SB吗？程序是不是老油条这样的桥段。我会告诉你，并不是他们多么的，而是他们在长期的沟通中，已经完全同步了。互相理解是因为，在同样的背景信息（Context）下，基于逻辑，得出了同样的结论。
The story of the Context thread is complete. If you ask me why I didn't write about the game designer being clueless or Programmer A being overly confident, I will tell you that it's not because they are exceptional individuals, but rather because they were completely synchronized through long-term communication. Their mutual understanding was based on the same background information (context) and logical reasoning, leading them to the same conclusions.

段子说完了，那要讲讲为什么我们的做事方式是“Context，not Control”呢？
Now that the joke is over, let's talk about why our approach is "Context, not Control."

在我们看来，Control往往会带来一些危险，人类在判断自己的理性控制能力时会有一种幻觉，对于聪明理性的人更是如此，常常抱有理性的自负。能力不错的人，往往有过一些成功的经验，不管是小成功还是大成功，如果很少被人Challenge，容易觉得自己英明神武。但是大家忽略了一点，行业是不断发展的，你所具有的知识虽然丰富，但在行业不断变化中依旧是有限的。即使自认为非常理性的人，有时候仍然会误以为，自己提出的方案特别好，模型特别优雅，希望把它执行，或者在全公司大范围内推行，但忽略了抽象知识和具体形式之间有差距。理性往往只适合做知识抽象，对具体问题的解决不一定真的有帮助。当然我们并不是要否定理性的作用，只是要避免过度放大理性会带来的危险。
In our view, control often brings about certain dangers. Humans have a tendency to have an illusion about their own rational control abilities, especially intelligent and rational individuals who often exhibit rational arrogance. People with good abilities often have some successful experiences, whether big or small. If they are seldom challenged, they easily perceive themselves as wise and invincible. However, we overlook one point: industries are constantly evolving, and although your knowledge may be extensive, it remains limited within the ever-changing industry. Even those who consider themselves highly rational sometimes mistakenly believe that their proposed solutions are exceptional and their models are exceptionally elegant. They hope to execute them or promote them extensively throughout the company but overlook the gap between abstract knowledge and concrete implementation. Rationality often only suits knowledge abstraction and may not truly help in solving specific problems. Of course, we are not trying to negate the role of rationality; we simply want to avoid the dangers that excessive reliance on rationality can bring.

自上而下的宏大战略往往都是灾难，业界也发生过不少真实的例子，对于一个公司，一个项目，都是如此。
Top-down grand strategies often lead to disasters, and there have been numerous real-life examples in the industry that demonstrate this, whether it's within a company or a project.

Control除了会带来战略上的问题，还会因为追求控制感而导致企业反应迟钝。
Control not only brings strategic issues but also results in sluggish responsiveness due to the pursuit of a sense of control.

相比Control，强调Context的管理模式有什么好处？
What are the benefits of emphasizing a management approach focused on Context compared to Control?

>
> 第一、分布式运算，让更多人参与决策，利用集体的智慧。对于组长，因为精力有限，做审批决策只花30分钟，但团队成员他们在一线决策有更丰富的外部信息，它可以花三个小时，做更多的调研之后才判断。
> Firstly, distributed decision-making allows more people to participate and leverage collective wisdom. For team leaders, their energy is limited, so they spend only 30 minutes on approval decisions. However, team members on the front lines have more diverse external information, and they can spend three hours conducting more research before making judgments.
>
>
> 第二、可以更快速的执行，不需要层层汇总，不需要汇总到一处，不需要所有决策在CEO或制作人这里排队列，能够更及时的响应。
> Secondly, it enables faster execution without the need for gathering and centralizing decisions in one place, without the need for all decisions to queue up with the CEO or producer. It allows for more timely responses.
>
>
> 第三、充分的外部信息输入。在Control的模式中，任何信息都要到CEO这个节点，靠CEO再分发出去，CEO很大程度变成了公司和外部之间的接口，相比单靠CEO接触外界情况，了解市场行业或者外部环境，让更多的同事，更多节点直接面向行业，信息确实会更充分，角度也不一样。
> Thirdly, it facilitates extensive input of external information. In a Control-oriented model, all information has to flow through the CEO as a bottleneck, who then distributes it. The CEO becomes the interface between the company and the external world. However, compared to relying solely on the CEO to interact with the outside world and understand the market, industry, or external environment, having more colleagues and multiple nodes directly engaging with the industry ensures more comprehensive information and diverse perspectives.
>
>
> 第四、参与感激发创造力。做同样的事情，如果团队成员知其然，也知其所以然，会比只知道指令，做起来更有意思。这个对于发挥团队成员创造力是有帮助的。
> Fourthly, it fosters a sense of participation and stimulates creativity. When team members not only know what to do but also understand the reasons behind it, they find the work more interesting compared to just following instructions. This is helpful in harnessing the creative abilities of team members.
>
>
> 第五、可规模化。Context的建设，表现形式可能是内部的系统，可能是知识共享文档，这些都是可以复用的，是可规模化的。而CEO和Leader们的时间、精力是有瓶颈，靠拼体力，脑力，耐力来解决，是有瓶颈的，是没有规模效应的。
> Fifthly, it is scalable. The construction of Context can take the form of internal systems or knowledge-sharing documents, which are reusable and scalable. However, the time and energy of CEOs and leaders have limitations. Relying on sheer physical and mental exertion to solve problems creates bottlenecks and lacks scalability.
>
>
>
>

当然，有时候也需要Control：
Of course, there are times when Control is necessary:

>
> 一、 紧急情况和重点项目。比如重大的玩家口碑危机需要快速响应。重点项目也是如此，如果竞争对手已经逼近，这个时候进行分布式的讨论，自下而上的涌现，来不及解决问题，时间窗口很快就过去了。所以紧急情况和处理重点项目需要Control。
> Emergency situations and critical projects. For example, a major player's reputation crisis requires a quick response. The same applies to critical projects. If competitors are closing in, engaging in distributed discussions and bottom-up emergence may not solve the problem in time, and the window of opportunity will quickly pass. Therefore, Control is needed in urgent situations and when dealing with critical projects.
>
>
> 二、 创新业务和新团队早期。如果一个新团队设立，或者一个新Leader刚加入，这个时候需要Control，新业务早期，需要更多支持配备资源的时候，也需要CEO统一协调，主导进展。
> Innovative business ventures and early stages of new teams. When a new team is established or a new leader joins, Control is necessary. In the early stages of a new business venture, when more support and resource allocation are required, the CEO needs to coordinate and lead the progress.
>
>
> 三、 不匹配的职位安排。某个岗位的人跟公司理念差距很大，那么他的Leader也是需要Control来干预的，比如一个资深运营同学，之前一直是做强商业化产品，游戏运营以拉收入为主。那么他的Leader在早期也是需要Control的。
> Mismatched job assignments. If an individual in a particular position significantly deviates from the company's principles, their leader needs to exercise Control. For instance, if a senior operations colleague has primarily focused on driving revenue through commercial products, and now they are assigned to game operations, their leader will need to exercise Control in the early stages.
>
>
>
>

### 2.3 Will I Be Fired?

我会不会被开掉？
Will I be fired?

答案是有可能的，而且是时刻都存在这个可能性。在被开掉这个问题上，我们倡导负责考核绩效的Leader不许手软。
The answer is possibly, and the possibility of being fired always exists. When it comes to the question of being fired, we advocate for Leaders responsible for performance evaluation not to be lenient.

历史的数据告诉我们：每四个离开miHoYo的同学，其中有一个就是被辞退的。
Historical data tells us that out of every four colleagues who leave miHoYo, one is dismissed.

那么我们一起盘点一下，当哪些情况发生时，你会触发这一“成就”。
So let's take stock of the situations that could trigger this "achievement."

**文化的匹配性**
miHoYo有我们自己的文化。这种文化并不是写在纸上，贴在墙上的那种。可以说我们的文化是一种味道，我们强调这种味道。这种味道来自于我们倡导的价值观，或者来自于经过集体多年磨合出的一套认为正确、应被倡导的工作习惯。我们希望在人才筛选和匹配的过程中，能够选择到具有相同味道的人。然而毕竟五湖四海汇聚一川，我们理解每个人的味道都会不一样。但如果miHoYo的味道让你很难接受，让你发自内心的不认同这个说到做到、有话直说、追求极致、只认功劳的价值观，或是在这样的价值观环境以及工作习惯下让你感到并不舒服。我们会请你离开。但请相信这不代表着你错了，也不代表你不优秀，而是我们不合适。就像恋爱一样：我们尝试了开始。但在一起生活之后，才发现没办法认同对方的习惯和价值观，这时无论谁提出分手都是最好的选择。
**Culture Fit**
miHoYo has its own culture. This culture is not something written on paper or posted on walls. We can say that our culture is a certain flavor, and we emphasize this flavor. This flavor comes from the values we advocate or a set of work habits that we have collectively developed and consider correct and worth promoting. In the talent selection and matching process, we hope to choose people who have the same flavor. However, given that people come from all walks of life, we understand that everyone's flavor will be different. But if miHoYo's flavor is something you find difficult to accept, if you sincerely disagree with the values of delivering on promises, speaking openly, pursuing excellence, and only acknowledging accomplishments, or if you feel uncomfortable in such a value-based environment and work habits, we will ask you to leave. But please believe that this does not mean you are wrong or not excellent; it simply means we are not a good fit. It's like a romantic relationship: we gave it a try. But after living together, we realized that we couldn't identify with each other's habits and values, and in such cases, breaking up is the best choice, no matter who initiates it.

**能力与认知滞后**
我们相互之间喜欢以同学相称，字面意思就是共同学习。共同成长。如果把2012年的miHoYo比喻成一艘小帆船，那么2018年的miHoYo或许就是一艘大商船。我们都明白这个道理：如果你仍然只掌握着驾驭帆船的能力，但今天的你站在了这艘大商船上，那么你的能力就跟不上组织的发展了。如果我们的目标是航空母舰，那么在这个组织不断变强的过程中，无论是舰长还是海员，组织对每一个人的能力要求都在提升。所以在我们发展的过程中，你必须要能跟得上组织发展的速度，不断去提升自己的认知水平。举个例子：如果在2006年，你无论如何给一位诺基亚工程师讲述今天智能手机的概念，他都不会理解。最糟糕的是，如果那位工程师自我感觉良好地认为“老子手机，天下第一”，基本他也就离手动再见不远了。而如果有一天你成为了那位“工程师”，那么在不远的将来，你也就有可能“被”离开了。因为我们要去更大更远的地方了，且这艘舰船也并不具备慈善机构的功能属性。
**Lagging Abilities and Awareness**
We call each other "colleagues," which literally means learning together. Growing together. If we compare miHoYo in 2012 to a small sailboat, then miHoYo in 2018 might be a large merchant ship. We all understand this principle: if you still only have the ability to navigate a sailboat but find yourself on this large merchant ship today, your abilities cannot keep up with the organization's development. If our goal is an aircraft carrier, as the organization becomes stronger, whether you are the captain or a sailor, the organization's expectations for everyone's abilities will increase. So, in our development process, you must keep up with the organization's pace of development and continually improve your level of awareness. For example, if in 2006, no matter how you tried to explain the concept of smartphones to a Nokia engineer, they wouldn't understand. And the worst part is, if that engineer felt self-satisfied and believed, "My phone is the best in the world," he would soon be far from the world of smartphones. And if one day you become that "engineer," then in the near future, you may also be "left behind." Because we are heading to bigger and farther places, and this ship does not possess the attributes of a charity organization.

**高压线**
踩高压线都会被“电死"。其踩法主要有两种：一种是因为蠢而踩，而另一种是真心实意，诚心诚意的踩。前者多数出于类似炫耀，觉得事儿不大、得瑟、吹牛逼、自欺欺人等等动机（实际的表现是将工作资料晒出或者将内部的信息/同事信息流出等等……），这种踩法可以被归纳为蠢，而且很有可能造成很多你根本hold不住的结果。所以这些因蠢而触犯高压线的同学事后往往会觉得自己很“窝囊”。其实最好的规避方式就是：在高压线面前，"Don't do anything stupid”，绝不在危险边缘试探。另一种踩法则是真心实意、诚心诚意的踩，这就比较危险了。针对这种“明知山有虎，偏向虎山行"的同学，一旦让我们明确这种动机，我们并不会自己去处理这个问题。miHoYo 2017年就成为了徐汇区公安局网安大队的重点保护单位，警察叔叔会直接立案并介入调查(他们一定有办法掌握他们想知道的东西)。游戏行业曾经出现过因蓄意信息泄露导致刑法落地的案例，我们不希望任何人成为miHoYo的第一例。
**Crossing the High Voltage Line**
Stepping on a high-voltage line will result in being "electrocuted." There are mainly two ways to step on it: one is stepping on it due to stupidity, and the other is stepping on it sincerely and wholeheartedly. The former is often driven by motives such as showing off, thinking that it's not a big deal, boasting, deceiving oneself, etc. (actual manifestations may include exposing work materials or leaking internal information/colleague information, etc.). This way of stepping on the line can be categorized as stupid and is likely to result in outcomes that you cannot handle. So, those colleagues who step on the high-voltage line due to stupidity often feel very "helpless" afterward. The best way to avoid it is to remember: in front of the high-voltage line, "Don't do anything stupid" and never test the dangerous edge. The other way of stepping on the line is stepping on it sincerely and wholeheartedly, which is more dangerous. For those colleagues who "knowingly walk into the tiger's den," once we identify this motive, we won't handle the problem ourselves. miHoYo became a key protected unit of the Xuhui District Public Security Bureau's Network Security Brigade in 2017, and the police will directly file a case and investigate (they definitely have ways to obtain the information they want). The game industry has seen cases where intentional information leaks led to criminal prosecution, and we don't want anyone to become miHoYo's first such case.

**我搞砸了怎么办?会不会被开掉?**
miHoYo没有一次因为谁犯了错而开除他的历史。任何错误都是反思教训的机会，如果犯错就该受到惩罚，那么miHoYo就会变成一个谁都不敢多做事的公司了。如果多做多错，那么价值从哪里来？我们鼓励尝试，鼓励创造更多的价值。工作中犯错在所难免，我们绝不苛责犯错的结果，更不会因为犯错就开掉谁。但我们也绝不认为犯错是件天经地义的事，尤其是在研发环境中。我们主张组建能力高密度性的团队;每个人都很强，在执行中就会降低犯错的几率。就算你是个毕业生或初学者，也不能认为自己就矮了别人一头，犯错就是天经地义的， 要为别人给你擦屁股这件事而感到羞愧。想不犯错误就要认识到自己弱。就要鞭策自己迅速成长起来，变得更强。
**What if I mess up? Will I be fired?**
miHoYo has no history of firing someone for making mistakes. Any mistake is an opportunity for reflection and learning. If punishment is imposed every time a mistake is made, miHoYo would become a company where no one dares to do anything. If you make more attempts and mistakes, where will value come from? We encourage trying and creating more value. Making mistakes at work is inevitable, and we never blame the consequences of making mistakes, nor will we fire anyone just because they made a mistake. However, we never consider making mistakes to be something normal, especially in a research and development environment. We advocate for building teams with high-density capabilities, where everyone is strong, reducing the probability of making mistakes in execution. Even if you are a graduate or beginner, you should not think that you are inferior to others and that making mistakes is normal, making others feel embarrassed to clean up after you. To avoid making mistakes, you need to recognize your weaknesses. You need to push yourself to grow quickly and become stronger.

**什么时候你可以炒了米哈游?**
当你认为自己的能力被低估了、 自己被当做傻X看了、我的汇报关系没有资格评价我等等……这时欢迎你直接发邮件（forrest@mihoyo.com)给大伟哥，告诉他：“我的薪酬、奖金对不起我付出的贡献”请放心，他一定亲自会处理这件事的。
**When can you get fired from miHoYo?**
When you feel that your abilities are undervalued, that you are being treated as a fool, that your reporting relationships are not qualified to evaluate you, etc. In such cases, feel free to email Brother Wei directly (forrest@mihoyo.com) and tell him, "My compensation and bonuses do not reflect my contributions." Rest assured, he will personally handle the matter.