最新

在我们的初创公司，工程师不再直接构建功能。他们构建的是可以与内部工具（如 Zapier、Make 和 N8n）连接的 API。大多数“功能”，例如运行 SQL 查询或在产品 X 被订购时发送推送通知，都是由运营或产品团队利用这些工具构建的。 如果你有想法，就自己构建并发布。这种方式快速、赋权，并且让工程师专注于构建可靠、可扩展、安全的 API。同时，这也迫使我们编写更好、更简洁的 API，使其保持无状态和专注。调试可能会很困难，有时临时解决方案的逻辑会悄然堆积。 我认为这比传统模式要好，后者往往使工程师成为每个新流程的瓶颈。还有其他人尝试过这种设置吗？它在哪些方面存在问题，还是说这已经成为新常态？

我正在管理一位长期团队成员，但他变得越来越难以捉摸。他看起来很礼貌、合作，从不公开反对。他会承认请求，参加会议，并以专业的方式回应。 但实际上： * 任务一次又一次地半途而废 * 反馈被承认后又被忽视 * 错误被模糊的回应掩盖，比如“我这边没问题” * 有时消息得不到回复，或者他们声称“忙，没看到” * 他们从不说“不”，但一切都陷入了缓慢的磨蹭中 他们并不是公开的不服从，只是让人感到疲惫。 我们无法轻易解雇他们，因为他们在这里工作超过10年，从未违反过任何规则。但在过去几个月里，他们已经变得完全不可靠。 有没有人处理过这种被动抵抗的情况？你们是如何真正“推动”这样的人，还是选择将他们搁置一旁，尽量减少损失？