Return to Spotswood

There was once a great Australian movie called "Spotswood", about an efficiency expert sent to a small company producing automotive parts with the intention of improving efficiency & potentially laying off workers. When the expert gets to know the workers, & how their inefficient ways create a culture of camaraderie & new skills that could be of benefit to the survival of a more diversified business, he regrets the recommendations he had made on financial & professional assessments alone.

Watch the movie. Anthony Hopkins is brilliant. Russell Crowe doesn't spoil it. Toni Collette is sane.

The point I will get around to eventually is that you can't assess a team's efficiency by looking at its output alone, or its contribution to revenue. You have to also look at its potential for benefiting the company in other ways - such as their ideas & innovation potential, a feeling of well-being or loyalty that keeps staff turn-over low, or simply the store of knowledge that they represent across the business & the industry as a whole.
The object of the game is for management to recognise & harness that potential.

Over many years in the IT industry, I have seen a slow shift from a somewhat haphazard approach to managing professionals from a distance, to a tight-reined structure where the professionals manage themselves, in theory. In the former, it was easy for a clever professional with a little time on their hands to come up with crazy projects & work on them in their spare time (staying back) or in slow periods. It wasn't particularly encouraged, but there was an air of mad scientist about it.
In a modern methodology like scrum, this is less likely to happen. Pair programming means that when one person leaves for the day, the task is dropped; & there is less likelihood of having things on the back-burner, because we think in terms of getting things to "done", then moving on. Where is the opportunity to put something aside for "later"?

You could argue that that is exactly what refactoring stories & the like are for - except that they are planned in (& are usually the first to get shunted from the sprint under pressure). Therefore, the spontaneity, the creativity, etc, are somewhat dimmed or forced (refactor for four hours on the last day of the sprint). Some companies encourage their developers to contribute to open-source projects. Usually, this encouragement is carrot-&-stick: all open-source code used must be contributed to, religiously; only projects related to work are considered.

What is needed is more than a tentative understanding that a professional will, on average, use their time wisely & generate the product needed to keep the business going forward, & still have time to do "cool stuff" along the way - when they get around to it. There needs to be a formal process whereby people ask their manager something like "I want to spend half a day tweaking my widget discovery algorithm - you cool with that?" to get a languid "sure, but if you're still doing it tomorrow, you owe me some serious first-level support time".

It's a matter of trust & professionalism on the part of both the dev & their manager. It doesn't matter what the methodology is, this approach to treating people (employees) like adults, rather than machines, must benefit all.
You never know - that widget discovery algorithm might be the basis for a patent or a new product one day. Or you can just think of it as a learning experience that was much cheaper than sending someone on a course.