Alternative titles I considered: “The Argument Against Knowledge Sharing”, and “Yet Another Post About Story Points”.
I was reading an excellent introductory article about collective computing recently, where it talked through the modes and advantages, about how it learned and adapted and so on. One of the key parts was about how a highly successful network was not one of identical nodes with identical sensors and capabilities, but one where individual nodes had different capabilities and could bring those to bear on different tasks, improving the overall achievement of the network.
You know where I’m going with this.
Every team I’ve worked on has a propensity of continuous improvers, people who are constantly, actively and intentionally learning new skills and information. Tech teams (and their associated employers) invest great effort into disseminating learning. To maximise on any learning, be it R&D or an organised course, they want to share that knowledge across all of their engineers. If Alice is on a course this week, then she might well be scheduled to demo what she’s learned next week. This is not only beneficial to the company, but also pleases those aforementioned continuous improvers who are in constant receipt of these learning broadcasts.
The example of the collective computing says that whilst the endeavour is good, perhaps the outcome is bad. That if we got too good at sharing our experiences with one-another, we’d all be the same, tackling the same problems with the same tools and the same insights, and when faced with a knowledge gap, using the same search engine keywords to seek out the same next puzzle piece.
Beyond the single use case pointed out, maybe there are other arguments for or against a goal of cultural / knowledge homogeny within a team?
What about consistency of estimation? Probably not. Whilst hour-level estimates might vary from engineer to engineer, story points are consistent since they are an evaluation of relative complexity, not likely to be affected by which group of engineers make that evaluation.
What about readiness? Meh, maybe. It’d be handy if all engineers were ready to work on all problems all of the time. But if they were capable of learning relevant knowledge before it was needed, it’s also perfectly reasonable to expect a professional engineer to be able to learn in a “just-in-time” fashion.
Learning is forgotten if not practiced or exercised. A heterogenous group of engineers is best able to solve a problem because they’ve all got different skills, different interests, and different recent a fresh experiences. Long may diverse knowledge reign in engineering!