| Table of Contents | ||||
|---|---|---|---|---|
|
...
同类人
我们团队的人真的很少。
并不是业务停滞、或者资金短缺，也不是因为没有人愿意来这里工作。
而是我们打心里不想雇佣那么多人。
我们不认为一个巨大的办公室、熙熙攘攘坐满人的企业就意味着成功。
与之相反，一个精简的、有进取心的小团队能让我们决策得更快，运转效率更高。
我们目前有20多全职位工程师，在今年剩余的时间里，我们很可能只会再雇佣几位工程师，并且限制了团队总人数。
我们团队真的不适合大多数人，是真的不适合。
我自己就是一个疯狂的代码和业务推动者，经常在周末想到点子就要去做。
所以当你进入团队看到密集的代码提交和内部信息流，很可能感到慌张和压力。
但这对我们来说却是常态：休息要充分，输出要高效。
我们非常认真地对待自己的工作，并且为了成功，你必须有壮志雄心。
我始终认为好的工程师写出的代码，从许多方面都要好过 CSDN 复制粘贴工程师10倍不止。
30个人的精英工程师团队交付能力，二流团队需要200人才能跟得上，后者有大量时间是在内耗和写Bug。
话虽如此，我们正在招聘一些人。如果你真的一字不差的看完这些话并感到认同，怀揣做出世界一流水平产品的抱负，请告诉我们！
OKR
我们每两个月会对齐一次 OKR。
这是对齐团队目标的重要方式。
我们不喜欢 OKR 有车轱辘话，喜欢讲实际，是什么就是什么。
我们不喜欢「把手」、「赋能」、「打法」、「闭环」… 这些互联网黑话。
我们不喜欢大量形容词，尽量让队员的指代是清楚的。
团队的 KR = 个人的 O 的参考（部分），依次对齐。
OKR 的 KRs （关键结果）必须是 可衡量 的，但 不琐碎 的。
OKR 是有挑战性却⼜不⾄于让⼈绝望的。
OKR，你⼤约抱有 50% 左右的信⼼。
队员不必担心 Review 的时候无法完成你所有的目标，可量化的 KRs 已经证明了队员做了哪些努力。
做好失败的准备，准备好从失败中学习，并重试。
守门员测试
我们通过守门员测试来作为队员去留的重要依据。
守门员测试是：根据一个成员过去一段时间的总体表现所作出的评价。
绝大多数情况下，你会获得「符合预期 👌」的结果，这是正常情况。
当队员获得「低于预期」的红牌，HR 和上级会直截了当地告知原因，并留出时间改进，通常是1个月。
1个月后我们会 RE-TEST，重新进行守门员测试。
「依然不符合预期」，则意味着：即便我们付出了努力，还是无法让双方满意。
多次守门员测试结果的累积，会是团队不定期审视现有队员职级时的参考依据之一。
这个守门员测试：不是弄着玩的，不是制造恐惧，不是上级的暴政，不是末位淘汰，不是固定比例给“评价”这种机制，不是鼓励成员去讨好上级，而是凭真实产出说话。
总之它让不想继续待的人，尽早体面地分手，好聚好散。
让想做好的人，安心做得更好。
Same Category
There are really very few people on our team.
It's not that business is stagnant, or short on funds, or that no one wants to come work here.
It's that we don't want to hire that many people.
We don't think that a business with huge offices, bustling with people, is a success.
Instead, a small, lean, motivated team allows us to make decisions faster and run more efficiently.
We currently have over 20 full time engineers and will likely Our team is purposely small and lean, with a focus on efficiency and fast decision-making.
We believe success is not measured by a bustling office filled with countless employees.
Instead, we currently employ over 20 full-time engineers, but plan to only hire a few more for the remainder of the year and limit the total team size.
Our team really isn't We understand that our team is not a good fit for most people, it really isn't.
I myself am a crazy code and business driver, often coming up with ideas on the weekends and doing them.
So when you enter the team and see the intense flow of code commits and internal information, it's likely to be flustered and stressful.
But this is the norm for us: to be well rested and productive in output.
We take our work very seriously and in order to succeed you have to be ambitious.
I have always believed that good engineers write code that is in many ways more than 10 times better than CSDN copy-paste engineers.
It takes an elite team of 30 engineers to deliver what it takes a second-rate team of 200 people to keep up, and the latter spend a lot of time writing bugs.
That said, we are hiring some people. If you really read these words and agree with them, and have ambitions to make a world-class product, let us know!
OKR
We align OKRs every two months.
This is an important way to align the team's goals.
We don't like OKRs to be rhetorical, we like to be realistic, it is what it is.
We don't like "handle", "empowerment", "play", "closed loop"... these Internet words.
We don't like a lot of adjectives, and try to make the team members' references clear.
Team's KR = Individual's O's reference (part), aligned sequentially.
OKR's KRs (key results) must be measurable, but not trivial.
OKRs are challenging but not desperate.
With OKRs, you have about 50% confidence.
The team does not have to worry about not accomplishing all of your goals during the review; the quantifiable KRs already demonstrate what the team has done.
Be prepared to fail, be ready to learn from your failures, and retry.
Keeper Test
We everyone as we have a high demand for productivity and ambition.
Good engineers ensure that code is written efficiently, and it takes an elite team to succeed.
If you believe in our values and have ambitions to create a world-class product, we would love to hear from you.
OKR
To align our team goals, we use OKRs every two months, which must be realistic and measurable.
We do not use ambiguous internet jargon and ensure that team members' references are clear.
Our team understands that challenges come with setting OKRs, and that not all goals may be achieved. However, the quantifiable key results already demonstrate what we have accomplished.
Failure is part of the process; we're always prepared to fail, learn, and try again.
Keeper Test
In evaluating team member performance over time, we use Keeper Test as an important basis for player retention.
A Keeper Test is: an evaluation based on a member's overall performance over time.
In the vast majority of cases, you will get a result of "Meets Expectations 👌", which is the normal situation.
When a team member receives a "below expectations" red card, HR and supervisors will be upfront about why and allow time for improvement, usually 1 month.
"Still not meeting expectations" means that even with all the effort we put in, we still can't satisfy both parties.
The cumulative results of multiple goalkeeper tests are used as a reference for the team to review the ranking of current team members We aim for team members to meet expectations, and if they don't, we give them a month to improve. If they still can't meet expectations, we will part ways.
Cumulative results from multiple keeper tests are used to review team member rankings from time to time.
This Keeper Test test is not a game, not a fear-mongering, not or a tyranny of superiors , not a final elimination, not a fixed percentage of "evaluations", not a mechanism to encourage members to please superiors, but to speak on the basis of – it's a basis for real output.
In short, it allows people who do not want to continue to stay, as soon as possible, a decent breakup, a good separation.
Let the people who want to do well, Our goal is to let people who aren't the right fit go decently, and allow high-performing team members to do better.