《裁员、降薪、996、PUA...... 你有没有想过,为什么混职场这么艰难?》
下图是传统的职业发展路径,问题的答案就藏在这张图里 —— 在传统的职业发展路径中,职场人的每一步决策都依附于“公司”这个载体。
在经济下行期,当你还执着于卷知识、卷同事时,公司经营不善对你来说就是降维打击。
在我看来,最具性价比的选择是跳出`依附于公司`的职业发展路径,我们可以:
- 向下看:依附于个人
- 向上看:依附于行业
所谓`依附于个人`,就是在工作之余根据个人禀赋做些副业。如果你在工资之外还有副业收入,那你对公司的依附将大大减少。
虽然`依附于个人`提供了一条有别于`依附于公司`的新路径,但他也有很多缺点,比如:
- 副业可能做不长久
- 并不是所有人都有能力做副业
- 副业的长远发展可能不如主业
所以,对于专业人士,我更推荐的是`向上看,依附于行业`,也就是成为领域专家。
一旦成为领域专家,你的职业发展不再受限于公司。以我的亲身经历举例:
- 依附于公司发展,当你跳槽时,你需要向目标公司投递简历,再与其他面试者一同竞争岗位
- 依附于行业发展,成为领域专家,当你想跳槽时,对你专业能力感兴趣的公司会主动向你抛出橄榄枝,面试的过程更类似于你的粉丝见面会,面试官对你的态度是“请教”而不是“审查”
除此之外,你也能利用领域专家的影响力吸引一批粉丝,为粉丝提供价值。这是一种比一般副业更稳定且长久的商业模式,名为圈层生意。
`成为领域专家`对大部分人来说是个遥不可及的目标。但我认为,对于有志于此的年轻人,卡点并不在于个人能力,而在于`不知道具体该怎么做`。
首先我们要明白 —— 别人为什么会认为你是专家?简单来说,他的问题你能解答,他就会认为你是该领域的专家。
那再进一步,为什么你能解答他的问题?
因为你对于该领域有一套原创的体系知识,这套体系知识是对该领域下一类共性问题的解决方案。
举个例子,一个前端看了我写的《React技术揭秘》后,对`React源码`有了理念、架构、实现三个层面的理解。
当他有一个`React源码`相关的问题时,即使书中没有直接给出答案,但他仍可以在书中理论框架的指引下自行找到答案。
也就是说,《React技术揭秘》作为`React源码领域`带有共性的解决方案,可以解决读者关于`React源码`的个性问题。
正因如此,大家就会认为我是`React源码领域`的专家。
这也解释了为什么很多人都写过零散的`React源码解析文章`,但他们在`React源码领域`影响力不如我大呢?
因为零散的文章只是`文章作者个性化的知识`,个性化的知识不一定能解决读者的个性化问题。
很多同学也想像我一样成为领域专家,但他们只看到我写了《React技术揭秘》,于是就尝试在自己擅长的领域也写一本电子书。
他们写书的路径通常是:
1. 选定一个自己擅长的领域
2. 模仿其他同类书的目录结构列一个目录
3. 根据目录结构一点点完善书的内容
这么做通常会遇到两个卡点:
1. 自己熟悉的章节可以顺利写出来,其他不熟悉的章节写起来很困难
2. 即使写出来了读者也少
之所以遇到这两个卡点,是因为他们只看到我写了《React技术揭秘》,但他们不知道书背后的迭代逻辑。
刚才聊到,体系知识是对该领域下一类共性问题的解决方案。
所谓`共性`,是从大量`个性`中总结抽象出的。比如`React源码领域共性解决方案`的前提是`解决React源码领域的各类个性问题`。
当个性问题解决多了后,就能从中抽象出共性解决方案。而书的目录本质只是将这套共性解决方案以“方便读者阅读的形式”展示出来罢了。
就我的例子来说,我是因为业务线大量使用了一个`类React框架` —— `Anu.js`(作者是司徒正美老师)。为了解决框架小bug,不得已开始阅读`Anu.js`源码。
后来,业务需要降本增效,我想从框架层面寻找机会,于是尝试从`React源码`中寻找灵感。
正是在很多个性化源码问题的驱动下,才使我最终抽象出`共性的React源码解决方案`。
共性解决方案是`因`,书的目录是`果`。
总结下,我认为,造成当前职场人困境的主要原因是`职业发展完全依附于公司`。学再多知识、再努力工作都无法跳脱`依附于公司`的限制,这就是我最近技术文章更新减少的原因。
更有前景的职业发展路径是`依附于行业`,也就是成为领域专家。
为了成为领域专家,你需要总结一套原创的体系知识,这是对该领域一类共性问题的解决方案,他能解决领域从业者的个性化问题。