朱赟的技术管理课
朱赟
计算机博士,前Airbnb技术经理
立即订阅
11176 人已学习
课程目录
已完结 39 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 | 从工程师到管理者,我的思考与实践
免费
01 | 职场分身术:从给答案到做引导
02 | Bug引发事故,该不该追究责任?
03 | 每个工程师都应该了解的:A/B测试
04 | 如何帮助团队成员成长
05 | 当我们给别人提意见时,要注意些什么?
06 | 每个工程师都应该了解的:聊聊幂等
07 | 当别人给我们提意见时,该如何应对?
08 | 说说硅谷公司中的一对一沟通
09 | 每个工程师都应该了解的:大数据时代的算法
10 | 项目延期了,作为负责人该怎么办?
11 | 管理和被管理:期望值差异
12 | 每个工程师都应该了解的:数据库知识
13 | 管理者在进行工作分配时,会考虑哪些问题?
14 | 硅谷人到底忙不忙?
15 | 每个工程师都应该了解的:系统拆分
16 | 技术人如何建立个人影响力?
17 | 管理者不用亲力亲为:关键是什么?
18 | 每个工程师都应该了解的:API 的设计和实现
19 | 硅谷面试:那些你应该知道的事儿
20 | 项目管理中的三个技巧
21 | 每个工程师都应该了解的:中美在支付技术和大环境下的差异
22 | 不要做微观的管理者
23 | 如何处理工作中的人际关系?
24 | 编程语言漫谈
25 | 兼容并包的领导方式
26 | 如何做自己的职场规划?
27 | 小议Java语言
28 | 如何激发团队人员的责任心
29 | 说说硅谷互联网公司的开发流程
30 | 编程马拉松
31 | 工程师、产品经理、数据工程师是如何一起工作的?
32 | 硅谷人如何做 Code Review
33 | 技术人的犯错成本
34 | 如何从错误中成长?
35 | 理解并建立自己的工作弹性
36 | 如何对更多的工作说“不”
尾声:成长不是顿悟,而是练习
新书 |《跃迁:从技术到管理的硅谷路径》
朱赟的技术管理课
登录|注册

33 | 技术人的犯错成本

朱赟 2018-01-26
今天和你分享一下我和周围一些朋友在职场曾经犯过的错误,供你参考和反思。基于表述的方便,我会采用第一人称或我的同事或朋友的方式讲述,读者们无需对号入座。

错误一:所有关于公司公关层面的事都不是小事

尤其是公司规模大到一定程度,这种事情更应该小心处理。
很多技术人都喜欢分享,但是分享的过程中要避开公司公关层面内容,更多去分享自己的技术和成长体验。比如我的公众号“嘀嗒嘀嗒”里,很多读者会留言:“安姐,可以说说 Airbnb 的某某方面怎么做的。”
这其中有很多内容可以写,但更多的内容是相对敏感的,不合适在个人作者的公众号里披露出来。所以我很少在公众号写公司的事情,毕竟“嘀嗒嘀嗒”并不是 Airbnb 的官方宣传工具,而是个人创作平台。以前我曾经出过类似的问题,一不小心,就会惹出不小的麻烦。
我曾在一篇文章中提及了 Airbnb 使用的一个第三方服务,表述方式其实都算不上负面评价,只是言辞中指出了这个公司的一些产品的瑕疵,结果该公司的公关直接联系了我们公司的公关及我们组的负责人,说这样的文章对他们公司的产品有负面影响。
最终这件事的结果是我把那篇文章删除了事,但是若细究起来,我也有被辞退的可能性。一个人具备了一定的影响力,所有公开的言论都可能会被认为,你代表了公司的观点。从那以后,我就很少去写公司相关的具体事件了,就算有涉及的也会泛泛带过。
后来我开始负责 Airbnb 的官方博客,每一篇博文的发布都是要经过公关审核的,当用户量形成规模之后,每一篇正式的稿件,如果措辞模棱两可,都可能引起误读。
作为技术人,如果你在任何场合有公开演讲或者文字输出,都要谨记自己可能被默认是公司的代表。

错误二:人事变动的宣布一定要谨慎

有一次,某公司空降了一位技术经理,不过按照公司惯例,一线的技术管理岗位都是需要做大概半年的工程才能正式转岗成为管理者。
所以,虽然大家都知道:只要半年内没有大的问题,他就会成为技术经理;但是,这个任命并不是立即宣布的。结果一位不明就里的同事给全组发邮件,欢迎这位新的技术经理,事情就弄得比较尴尬,管理层也觉得流程上出了问题。
类似的事还见过几次,比如,老板还没宣布谁离组离职,某同事就在公开的邮件中就提及此事等。或者在一些群组里,把未公开的、很多人其实并不知道的人事变动透露出来,显得自己消息灵通。在职场上来说,这些都是很不专业的举动。
这么做的代价有可能会让事情变得很糟糕,你也会失去领导和伙伴的信任。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《朱赟的技术管理课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(11)

  • 缪文@场景鹿
    在淘宝工作时,曾因一行代码错误,导致百万商品下架,数十万商家被处罚,甚至关店。
    2018-08-04
    11
  • 程序猿爸爸
    刚入IT行业没多久,在公司因为业务部门需要,我第一次手动执行一个存储过程,使用toad工具的时候,准备点击Execute Procedure的时候手一抖点成上面的Drop Procedure。紧接着惯性思维都是点击确定....然后,一个6000多行的procedure被我完美的删除了..然而数据库备份查找那时我根本不懂,只能去向领导请罪,寻求解决办法,至今难忘。
    2018-01-26
    7
  • GeekAmI
    曾经犯过把测试代码推到了线上
    2018-01-26
    5
  • Grapef
    这篇总结得太好 所有的这些我都有亲身经历 作者能总结出来告诉新人和次新人太好了 等发生问题再总结往往太晚了

    池建强回复: 专栏的目的就在于此

    2018-01-27
    3
  • songyy
    刚入职一家支付公司时 负责了写meeting minutes (会议记录)。当时顺手写: “xx这个模块的设计,是由yy说了算的。我们要在会议之后询问一下yy的意见”,并在会后发送给了与会人员。

    刚发完,一个很有经验的员工就紧张的跑来找我,说zz和yy是平级的,这里不能够说什么东西是由yy说了算的。

    当时感觉的确是自己不小心了,但是这家公司的politics好严重啊。。不知道大家怎么看 😂
    2018-01-26
    3
  • Alexis何春光
    看到songyy的留言,个人不觉得这是politics中的表现,反而是professional的表现,尊重每一个人的职位和角色。
    2018-12-26
    1
  • Danny.zhu
    最近犯了两个错误:
    一个是在向公司内部sales分享信息时把一个internal服务说成public facing。对public facing理解错了。经理用upper case纠正了这个信息,心里那个汗啊。

    第二件学到的是回邮件要看收件人角色。我在中途被拉入一封邮件做support,花了几分钟浏览上下文后回了封技术邮件给提问的人,经理补了一封说这个邮件suppose to给另一个人。在当时还纳闷为什么,后来仔细一看,发邮件的人是个经理,另一个人应该是真正做代码过的人。事后悄悄给经理发了个感谢:)

    池建强回复: 处理的很好,这篇文章该早读到

    2018-01-26
    1
  • mikejiang
    犯错成本大小并不会防止出错,能做的就是小心谨慎,发布多检查,灰度发布,sql语句执行必须提前准备好,禁止临时写sql. 大部分时间是要用只读账户登录
    2019-12-03
  • AlphaGao
    我两次格式化了公司的公共资源盘,都是自己买数据恢复软件恢复的...
    2019-07-18
  • self-discipline
    有一次都说我把测试库给删了,但是我查看我的本地历史记录就没有删库的,最后不了了之的,我把我本地客户端的sql记录,若干天的都找出来了,是我的责任我不推脱,不是我的锅,我也不背
    2018-07-25
  • yiluo
    第一次认识到DBA的作用就是错删了一个数据库(还好不是线上的,但是开发在用,重建很麻烦),DBA根据其他的文件和log把数据库恢复了。
    2018-07-17
收起评论
11
返回
顶部