An Impact Guide for Engineers
https://medium.com/@erand/we-are-all-product-owners-an-impact-guide-for-engineers-76a2b4342c74
非常好的一篇文章。做许多事情，我们不仅仅要关注需要做什么，还要关注做这些事情的目标是什么，产生什么样的影响，学习和收获到什么。从目标开始逆向思考，选择做那些可以产生影响的事情，也是一种做事情的方法。
虽然很多事情是没有办法衡量的，但是你依然要习惯于衡量事物。
There are a lot of other ways to impact the company, so long as they tie to those goals:
- Reducing incidents
- Fixing a major set of bugs for a product area to make it better for users
- Increasing performance in user noticeable areas
- Making infrastructure cheaper / faster / more stable
- Building systems and frameworks that help others build things faster (and are adopted)
- Reducing developer time to diagnose / build / ship
- Increasing the number of quality people you hire
- Mentoring (and having the mentees acknowledge that you helped them)
- Etc.
Not everything is measurable. While not everything is measurable, you should cultivate a bias towards measuring.
看看下面这个例子，你可能会更加明白为什么要关注measurement和impact. impact和measurement可以说是孪生兄弟。
Without thinking about the impact you’re having, you might just be wasting your and other people’s time.
Thinking about impact throughout the product creation process takes different forms.
Consider what your company’s performance reviews emphasize. Do you get rewarded for motion (shipping), or for progress (impact)?
The goal is to reward people who make good decisions. Some luck is involved in everything we do, but think about the following two people’s performance over 3 consecutive performance review cycles. The Engineer’s Engineer:
- Term A: Great planning, project didn’t pan out.
- Term B: Great coding skills, projects had minimal impact.
- Term C: Architect-level thinking about the system, caused 4 teams to have to rewrite their interfaces. A way to make the current system better was discarded since it wasn’t cool enough.
The “Lucky” Engineer:
- Term A: Ran lots of short-term experiments, 10% increase to Widget Production.
- Term B: Reworked the site’s design, 5% reduction in abandoned carts.
- Term C: Refactored backend stack, page load time decreased by 20% driving 5% decrease in bounce rate.
No one is THAT lucky. The “Lucky” engineer is making some smart choices. She’s picking the right projects, she’s finding ways to verify if something is worth doing, she’s evaluating work with the end result in mind.
The Engineer’s Engineer is wasting some amazing technical capabilities on the wrong things.
如何定义失败？应该如何看待失败？不能简单地将事情没有成功定义为失败，这个只是结果，我们应该更加关注过程。过程决定是否正确，是否可以及早发现错误，这个过程中是否可以学到什么东西。
Our definition of failure might differ:
- An experiment that shows that a change in the system will not improve the business is not a failure so long as you’ve learned something about your customers or your product.
- An experiment that you ran for 4 weeks, only to discover that you set it up incorrectly and have to rerun it is a failure of execution.
- A year-long project that fails is hard. Consider why it failed? Was there something you could have done to either make it more successful, or to learn earlier that it would fail? This is a management failure as well — why did this project start and why wasn’t it re-evaluated and stopped?
I don’t punish failure. I reward taking risk and success. Making the right choices and executing well will give you a much higher chance of success.