The Framing of the Developer
One of the most well-known companies using what the author calls “impact frame” is Facebook.<p>There, engineers’ promotions and perf used to be heavily dependent on their impact. Developers needed to be aware what the business impact of their work was, thus they needed to measure (using the excellent tooling available).<p>This model worked very well while the company was growing. Lots of features core to Facebook today were created by engineers, not product managers. Newsfeed. GraphQL. A/B testing frameworks.<p>The difficulty comes both when growth slows - and it’s hard to have impact without cannibalising another team’s impact - as well as when having more impact actually causes harm to the company on a different direction. While engineers were optimising for engagement, tweaking the news feed algorithm to show items you were likely to click on, sensationalist content (sometimes: fake news) was over-promoted. While the ads team optimised for ad engagement by exposing various metrics, they exposed metrics that turned to public uproar later on.<p>The idea of only optimising for impact is a great short-term strategy. Long-term it is not nearly as black-and-white.<p>My take is the optimum is in-between. Engineers should have an understanding and input on the business impact. But the strategy and prioritisation framework does need to come top-down, aligned with the long-term goals of the business.