We're sunsetting PodQuest on 2025-07-28. Thank you for your support!
Export Podcast Subscriptions
cover of episode Episode 436: Paralyzed by checkboxes and I'm on a "must keep happy" list

Episode 436: Paralyzed by checkboxes and I'm on a "must keep happy" list

2024/11/25
logo of podcast Soft Skills Engineering

Soft Skills Engineering
AI Deep Dive AI Chapters Transcript
People
D
Dave
活跃的房地产投资者和分析师，专注于房地产市场预测和投资策略。
J
Jamison
通过播客分享软件工程和软技能知识，帮助工程师解决日常工作中的问题。
Topics
Marcus Zackerberg 讲述了其在大型公司中遇到的问题：公司为了提高可靠性，实施了极端的监控措施，导致开发效率低下，团队压力巨大。他希望得到如何在这种情况下有效工作的建议。Dave 和 Jamison 认为，这种极端的可靠性措施虽然初衷是好的，但由于缺乏有效的沟通和管理，反而适得其反。他们建议 Marcus Zackerberg 尝试与团队领导沟通，说明目前的情况，并寻求改进。同时，他们也建议 Marcus Zackerberg 利用公司对他的重视，争取加薪或晋升。 Dave 分享了他之前在大型公司工作时遇到的类似问题：公司会将事故的经济损失归咎于特定团队，导致团队之间互相推诿责任。他认为，这种做法不利于团队合作和问题解决。Dave 和 Jamison 认为，过分强调可靠性指标会忽略其他重要因素，例如开发效率和团队士气。他们建议公司应该找到一个平衡点，既要保证服务的可靠性，又要保证开发效率和团队士气。 Jamison 认为，这种极端的可靠性检查流程无法长期维持，因为高层管理人员没有时间去审核工程师提交的报告。他建议 Marcus Zackerberg 等待公司自己发现并解决这个问题。同时，他也建议 Marcus Zackerberg 利用公司对他的重视，争取加薪或晋升。Dave 分享了一个例子，说明如何将繁琐的流程转化为职业发展的机遇，例如，精心准备一份申请文件，以获得高层管理人员的批准。

Deep Dive

Chapters
The episode discusses the challenges of working in a reliability-focused environment where processes like checkbox-driven development hinder progress. The hosts offer advice on how to navigate these challenges and turn them into opportunities for career growth.
  • Reliability measures can become targets that distort original goals.
  • Engineers should focus on strategic communication with leadership to highlight the negative impacts of extreme reliability measures.
  • Turning bad processes into opportunities for career growth by creating well-documented explanations for service health issues can lead to positive recognition.

Shownotes Transcript

In this episode, Dave and Jamison answer these questions:

-

Marcus Zackerberg asks,

I work at a megacorp whose recent focus has been on reliability. The company already has mature SLO coverage outage response standards, but my org has taken it to the extreme this year. For example…

There is now a dashboard of “service health” that is reviewed by engineering leadership. In it, services are marked “unhealthy” permanently upon a failing check (think HTTP /health). To return to a “healthy” state, one must manually explain the failure with an entry in a spreadsheet, which must be reviewed and signed off.

Increasingly I feel this has the opposite effect, discouraging nuanced work to improve reliability and instead becoming “checkbox driven development”, as well as impacting our ability to ship on our existing roadmap items. Additionally, our tech lead is fairly junior and frequently fails to communicate the org’s expectations to the team, leading to us being under the gun of the reliability dashboard often.

Any advice on how to make the best of this situation?

-

Hi Guys! I’m a senior engineer at a mid sized software company. The company has had a couple of high level departures recently, and during that process I’ve come into the knowledge that my name is one of a handful on a list of “engineers to keep happy”. I feel like this information should be of use to me, but I’m unsure on how I should leverage it.

On one hand it’s nice to know I’m valued, but I think I’d rather be explicitly told that or better yet, receive dollars in lieu of praise. I’m also at the point in my career where I’m looking for staff roles, and the topic of promotion has come up several times with my manager. He supports me (and I believe him), but we agree that it would be difficult to make the case to the business.

What do I do with this new knowledge, and is there a way to benefit from it without accidentally triggering a preemptive search for my own replacement?