4 ms·
I think this is one of those things where its a question of what you're optimizing for. I don't like boxing solutions into `10x` or `1x` or whatever. I think th
by no_wizard 5y ago
I think this is one of those things where its a question of what you're optimizing for. I don't like boxing solutions into `10x` or `1x` or whatever. I think this misses the entire point. It also assumes that single software engineers can make or break a project or company, and this is rarely the real case, even if it feels like it is.
I think an often missed piece in the formula is systematic incentives. At a company, this really means culture and process. If you have a culture and process of incentivizing novel solutions and so called `10x` behaviors, you'll have lots of `10x` developers, systems tend to produce the outputs that you foster. If you have proper incentives for high throughput, you will get it. No one engineer is "born" better than the other, like stated in the article, but a culture that fosters making good choices as a whole will see results align. This is how you can 10x your teams, regardless of individuals.
I think another way to look at is this: you're likely not the Yankees, you're the Oakland A's. Don't optimize for knockouts, optimize for runs[0].
[0]: https://en.wikipedia.org/wiki/Moneyball https://en.wikipedia.org/wiki/Moneyball
- BlargMcLarg 5y agoPretty much. There are various ways to optimize, but the far majority of them depend on circumstances almost fully controllable by the company, rather than a lucky shot getting more and more whizkids. Foresight, support and tutoring are three ways I can think of that would generate a "10x". Foresight in making better decisions which won't boggle down development later down the line. Support in the form of automating busy work, developing tools, removing impediments and making people more eager to develop (notice how some of these are not dependent on developers). Tutoring through making other people more efficient and raising new ICs. All three of these are highly dependent on circumstances set by management. You're not getting the time to automate if management continuously pushes you to fix issues and work on the next non-workflow-related issue. You're not getting a lot of time to think about the best solution if the first working prototype is what's expanded on despite there being obvious flaws requiring exploration. No quality teaching if individuals aren't given time to prepare teaching materials and others aren't given time to listen. The list goes on. In all likelihood you'll still need someone eager enough to go grab the knowledge and then distribute it in some form (how else are things going to change?), but it takes away the need to fill every position with a whizkid.