Skip to content

Engineering Management

Process

  1. The interface between engineering dept. and business/customer-support dept. should be clear, esp. on long-standing, important issues
    1. It should be a well-defined metric
    2. This metric is selected based on engineering expertise and business feedback
    3. We will add more / revise metrics based on business side feedback iteratively
  2. To solve any non-feature problem, directly relating to customer experience and developer productivity
    1. We should avoid writing new code, instead trying to innovate our process first 1. Improve customer support process => better experience without writing new code 2. Improve SRE process => better developer productivity without writing new code
    2. We should not be perfectionist, instead, be a ruthless, data-driven practitioner
  3. Meetings
    1. The goal of meeting is to reach consensus
    2. It is hard to reach any real solution in a general meeting. However, spark might come in an informal one
    3. Standup & fast

Motivation

  1. Make them feel productive and validated for his/her work
    1. Smooth the experience of development
    2. Effective goal setting, don’t change requirements or ops-ing too much
    3. Let him/her do the design and guide them through the validation process
  2. Make them feel growth and intellectual challenge
    1. Encourage innovation and experiment
  3. Establish our unique culture, spirit and workflow, a sense of team belonging
  4. Manage-up and push-back: Tractable and Transparent
    1. The engineers set goals for themselves based on business/ops requirements. However, they should be transparent about their progress and communicates actively
    2. The engineers have the rights and are expected to push back when some goals can be met within expected date. However, they should state their reason and discuss a more proper new date with manager. The manager is expected to help engineer to decide on the date more reasonably

[1] https://www.cleverism.com/google-way-motivating-employees/ [2] https://www.inc.com/ilya-pozin/14-highly-effective-ways-to-motivate-employees.html [3] https://stackify.com/measuring-software-development-productivity/

Leadership

  • Do your co-workers love to work with you?
  • Do they want to discuss problems with you?
  • Do they trust on critical things?
  • Do they respect your ideas?
  • Are they willing to work under your leadership?

Relationships

  • How to manage the relationship with CTO?
    • We need frequent communication, even if the communication might be one-sided or misunderstood. This also makes me learn and grow.
    • stress that you made X decision based on Y facts. If you am not authorized to do so, then you will stop crossing the line. If you am wrong, you will be responsible for it and trying to save it.
  • How to manage the relationship with CEO?
    • Express your technical perspective clearly & firmly
    • Tell the story backwards: I believe. We will. You can.
    • Manage expectations well
  • How to mange the relationship with other colleagues?
    • Build the culture of sharing and mentorship
    • Speak out openly but non-hurting
    • Connect with them personally. Learn from them.

Developers Types

  1. Frontier
    1. Add new code based on existing framework
    2. Communicate with business/product end
    3. Use our internal productivity tools
    4. Write unit tests and conduct smoke test
    5. Understand our product logic
    6. Meet immediate & strict deadline
  2. Core
    1. Architecture — Ability to understand the logics of our framework and design/develop it
    2. Performance — Ability to conduct system level performance analysis
    3. DevOps — Ability to create and manage the internal productivity tools
    4. Site Reliability — Ability to release code, being on-call, build monitoring and alarming system, plan capacity, and manage instances
    5. Security — Ability to address all security issues in our system
    6. Data Analyst — Ability to manage database, including managing permissions, writing data analyzer scripts, turning performance of database and data related code, ability to create meaningful report from our raw data
    7. Super Coder — Meet complex, long-term implementations goals with quality
    8. Domain Expert — expert in Data Science? Cryptography?
  3. Leadership
    1. Process Optimization
    2. Developer Productivity
    3. Interface & Communication
    4. Priority & Goal Setting

These two roles are not strictly assigned to each one. People might do both, might rotate. Our overall top-level system should permit such rotations without significant security risk exposure.

Misc

  • The necessity for communication and collaboration will naturally create the need for mechanism, common knowledge, and documentation

https://zhuanlan.zhihu.com/p/19887395 这个文章很棒

  1. 以前记住的是任务，现在记住的是目标；
  2. 以前没做好是你的错，现在团队的任何人没做好，都是你的错；
  3. 以前可能只需要记住上司的名字，现在需要记住所有人的名字；
  4. 以前想办法让自己比身边的人更优秀，现在要想办法让身边的人比自己更优秀；
  5. 以前总想做有兴趣有挑战的事情，现在要准备好做最无聊最艰难的事情；

其实 Leader 并不是想象中那样英俊潇洒，光芒四射，管理工作更不是想象中那样唯我独尊，轻松愉快。

https://www.slideshare.net/jeelchristine/theory-of-work-adjustment-45075959

  1. 成就：你如何看待工作成就感
  2. 舒适：你是否看中舒适和稳定的工作
  3. 地位：你是否追求晋升成为管理者
  4. 利他主义：你是否想做一份帮助他人的工作
  5. 安全感：你是否希望公司更透明更一视同仁
  6. 自主权：你是否希望获得更多自由发挥的空间

专家 vs 高管

人呐，还是要夹起尾巴，如履薄冰啊。

都比你私自做主强，不请示，就算你做的对下场也不一定好。 高调做事，低调做人 鼓励下属主动和你提加薪。

随着下属个人能力的提升，主动为其加薪。

不分场合批评下属

把责任推给下属

做好每天的计划。

浮浅工作时间控制在 10%

人总是这样，跑着想走着，走着想站着，站着想坐着，坐着想躺着，这是本性。 只有平时严格要求了，招之能来，来之能战，战之能胜，你才是真的对所有人负责。所以我平时对 Leader 的基本要求，就是别做老好人，要保持战斗力，解决问题。

很多技术牛人才转管理岗后最大的问题就是会陷入“被动管理” 的误区，有事情了，处理一下，问题发生了，解决一下。对下不能规划设定目标，碰到矛盾只知道和稀泥，有矛盾不决断期待大事化小小事化了，该处理该决断的时候拿不定注意（比如开掉一个有问题的人）；对上不能主动为大家争取利益，不能把大家工作量化让高层知道并认可大家的工作成绩，那是很失败的。

做技术就得这样静下心来把所有的问题加载到你脑袋的 cache 中，然后才能通盘考虑全面规划，两耳不闻传外事一心只读圣贤书，你才能进入创作的境界，并思如泉涌。

https://www.zhihu.com/people/ningnanshan/activities How to be an opinion leader?

https://blog.dbsmasher.com/2019/01/28/on-being-a-principal-engineer.html

https://www.robinly.info/blog/leadership-article?utm_campaign=leadearship&utm_medium=ad&utm_source=linkedin The WeChat favor

https://nickmchardy.com/2019/02/on-being-an-engineering-manager.html