[softwaredoug]

This has so many implications for software team design

Like hiring that one unicorn dev to solve X hard problem isn't a great "theory building" exercise. It can build theories for that one person, but without feedback they're never tested, they're never adopted by the whole team

So you actually NEED juniors, 'stupid' questions, outside points of view, and ways of openly and scientifically evaluating theories instead of defaulting to the authority of supposed experts. You also need to retain seniors who have context and a good historical working definition of the problem.

But a lot of teams are focused on just the next problem and "shipping it". Rather than using "shipping" to help the team develop a better theory of the problem.

The value isn't what's shipped, its the working knowledge of the team.

[antistaph]

Value of a product tends to be measured by the number of features shipped, the quality of service and time to market. But knowledge of the team is hard to evaluate and to sell to a manager.

It is good if developer has already it, he is more productive then. But when he explicitly puts effort into gaining knowledge, then he does not deliver during that time so maybe he should not be paid for it.

I can't imagine a relationship between a manager and a developer where knowledge is valued higher than delivery. It could work only if the manager also believes in this value. I think he could believe in it only if he is sure that this project will pay off in the long run. In the era of a fast-changing world, he is putting the value of delivery and satisfying stakeholders on a higher rung.