I try to harmonise the two forces at play - the business needs to make money but if you apportion work without regard to enthusiasm you risk losing developers. With respect to the "business features", knowing who has worked on what is super useful because creating "another damn form" may frustrate one developer but another hasn't done any for a year and could do with a few projects that require it. Not everything is interchangeable but a lot of it is. At the very least, this involves hearing developers (which can help prevent killing enthusiasm) and that's always a good mgmt role.
With the work that excites developers (that are NOT the core business focus), I view the development pipeline as a container full of stones. The big chunky stones that take the most space are the most visible/important projects that your company needs you to be doing. But a container full of big stones has a lot of space between for smaller stones. In dev, this is the space between projects - waiting for specs to be finalised, a dev that is blocked by external feedback, etc - there are many reasons why devs aren't 100% busy - and these gaps you can get to play with at your discretion (as a dev manager, although showing initiative as a dev with the "gaps" can speak well for your character and career). Getting a sense of what devs want to work with, it's useful to think of a few ways to allow some free reign to come up with new stuff. "We program in Python but you want to learn Golang? Got an idea of how this may benefit the company? Excellent - you have 2 (at most 3) days to try it! Build a microservice so the language doesn't cause us a headache and if it shows promise, I can motivate to upper mgmt to see it through." It allows some lee-way to experiment in a way that could still benefit the company, but which there is no shame or guilt in learning that it was a complete bust - 2 days is not going to sink the company. These little gaps could be broadened based on company culture but it's a matter of containing the time to experiment and getting the team to experiment in ways that may be useful. And this ability to have some (contained) risk while trying to keep developers happy should keep the big bosses happy.
I value any thoughts on this though.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I try to harmonise the two forces at play - the business needs to make money but if you apportion work without regard to enthusiasm you risk losing developers. With respect to the "business features", knowing who has worked on what is super useful because creating "another damn form" may frustrate one developer but another hasn't done any for a year and could do with a few projects that require it. Not everything is interchangeable but a lot of it is. At the very least, this involves hearing developers (which can help prevent killing enthusiasm) and that's always a good mgmt role.
With the work that excites developers (that are NOT the core business focus), I view the development pipeline as a container full of stones. The big chunky stones that take the most space are the most visible/important projects that your company needs you to be doing. But a container full of big stones has a lot of space between for smaller stones. In dev, this is the space between projects - waiting for specs to be finalised, a dev that is blocked by external feedback, etc - there are many reasons why devs aren't 100% busy - and these gaps you can get to play with at your discretion (as a dev manager, although showing initiative as a dev with the "gaps" can speak well for your character and career). Getting a sense of what devs want to work with, it's useful to think of a few ways to allow some free reign to come up with new stuff. "We program in Python but you want to learn Golang? Got an idea of how this may benefit the company? Excellent - you have 2 (at most 3) days to try it! Build a microservice so the language doesn't cause us a headache and if it shows promise, I can motivate to upper mgmt to see it through." It allows some lee-way to experiment in a way that could still benefit the company, but which there is no shame or guilt in learning that it was a complete bust - 2 days is not going to sink the company. These little gaps could be broadened based on company culture but it's a matter of containing the time to experiment and getting the team to experiment in ways that may be useful. And this ability to have some (contained) risk while trying to keep developers happy should keep the big bosses happy.
I value any thoughts on this though.