*** Disclaimer: this is not about my current team. It is about all teams, anywhere ***
Before you say it, I know what you are thinking. Bear with me for a moment please.
The first team that I lead, where I was officially sanctioned to do “discretionary development” was 15 years ago, and it worked great! Since then, it has been a hard sell, which is pretty disappointing.
The Problem: It is pretty common for dev teams to become organized to-the-point-where all work comes from prod-support or feature requests. Those come from the top, and get routed through BAs & tracked in work queues (in Jira or DevOps, etc).
Staying organized, orderly and predictable definitely has obvious benefits, but there is also a down-side. This structure usually prevents or blocks the developers’ from “coming up with” their own feature ideas or other improvements. If (when) a developer actually gets a good idea, or sees something wrong, the developer could request an audience with the person in-charge and is (usually) promptly told to “return to your desk and just do the work already assigned”.
So what’s the problem with that?
Developers have daily contact with systems, corresponding code & data. They will gain intimate knowledge of a system and come-across & observe “things that are wrong” or other shortcomings / problems within a project, program or system. Their unique perspective allows them to observe things non-programmers cannot (eg. might require a deep technical background to understand). Developers will also think-up utilities, upgrades, improvements, clean-ups and other ways to show craftsmanship, ownership and professionalism. Likewise, these kinds-of-things just aren’t going to occur to non-technical folks and therefore, probably will not be solicited or valued.
If you’re lucky, you might ask a programmer to explain why a proposed change will add value … and he actually will be able to express or explain it well. Unfortunately, communicating stuff like this (to non-technical people), isn’t really the strong-suit of most developers. Probably what would happen is, the developer will spout-out a bunch of jargon, and people won’t “get it”. If pressed, the developer will probably simplify the explanation to good-ole hyperbole, “Its good because you really, really REALLY need it! It is SUPER important!!” 🙂
How to manage it
Grant the developers a budget, like 10% of their weekly time, dedicated to development tasks/efforts of their choosing. It has to be work-related and it must be tracked, but they get to pick the work, define requirements, tests, objectives and priority. Give opportunities for developers to distinguish themselves and the project will be something they can be proud-of and care (more) about. Encourage developers to grow themselves by thinking higher thoughts.
Unexpected additional ROI
The obvious ROI is that the developers will make a system work-better, because “improvement” is now part of the job, and good ideas are welcomed from anyone. When excellence is everyone’s duty, you will get a better product, and the developers will try-harder and care-more.
The unexpected ROI happens when leadership/management learns from this. Hearing what the developers are thinking, isn’t the same as understanding the results. When you track the work, you can measure the ROI. Your next project might be significantly better because we all learned subtle (but good) things. You tried some of the ideas, and you saw where the ROI showed-up (which you otherwise might not have noticed). On top of that, you have conditioned the developers to teach you about their magic tricks, and maybe even understand it better.
Management now knows the names of these magic tricks, can inventory them, and communicate them. They are new tools in a PM’s toolbox.
…or not?
Believe it or not, I have observed developers who were aware of significant (underlying) needs within a system, but could not convince their leaders … so, they had to sneak-in several improvements. It was nuts. The developers were afraid of being punished for doing something necessary, but did it anyway. Management had no-idea why some projects flourished and others flopped. But they could’ve.
Don’t treat developers like code-jockeys. Give them opportunities to demonstrate craftsmanship, and take pride in their work. If they can’t express themselves eloquently or explain technical acrobatics to you, work with them on that. You will get better developers, better systems and better teams.
Aah, the pain of being an elitist 