Prioritization is never a straightforward process. We have a lot to consider in terms of user needs, business value, etc. But there is also developer enthusiasm. What role, if any, should this be a factor in choosing what to work on?
How much of a role should "enthusiasm" play in the software development process?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (14)
Its complicated.
I cant comment on the prioritization by user needs, business value etc. Cause I'm not product. But as a engineering manager I can say happy engineers become less happy if they do not feel "heard". If you want your team stable and consistently bringing product value its best to mix in wins for product to build up good karma with their engineers.
Maybe you read this and you say no product/business value only. We pay these people to write software you dont get to influence this. I would respond that people are complicated and coding is often a creative endeavor. Nothing kills creativity like being burnt out, upset, or tired.
Agreed
False dichotomy. Developers should be enthusiastic about solving a problem using the appropriate tools, with an eye to beauty in the code (as the opposite of complexity), and efficiency in how they work. They should have near carte blanche over how they're going to solve the problem, but not over what the problem is.
(Unless they manage to convince three business that the problem is actually elsewhere... that's legitimate).
But the idea of choosing the next bit of work based on Brad's burning desire to write some React or whatever? Smh, tell Brad to grow up and if he quits I'd breathe a sigh of relief. This infantilising of developers has got to stop.
An enthusiastic person would be someone that is easy to work with, is excited about a lot of things, jumps at opportunities, etc. Not someone willing to work after hours without the need to do so, learn new tech just for the job without being paid, etc. more or less someone who enjoys doing their work but doesn't live and breathe it.
Enthusiasm is something that is commonly found among older developers, while you find passion in newer developers.
Interesting question. I don't have a short answer, only some observations.
Overall, I guess I'm in the camp of having user needs & business value be the guideposts for prioritization. I think I'd define business value more inclusively than many; paying down tech debt, for example, often provides business value by my standards. That said, my bar for some stereotypical enthusiasm projects ("let's rewrite our stable customer-facing backend in golang!!!11") is pretty high. They're fun to do for an engineer, and maybe address some benign but offensive code smells, but hard to justify the opportunity cost if they take time away from work that produces more direct value, especially if what they're fixing is "good enough" overall.
I think as we get more senior as engineers, we tend to do a better job of connecting things that we're enthusiastic about for our own reasons to business value/user needs/etc. For example, helping to justify a refactor or code cleanup by understanding the product roadmap, or identifying a business/user-facing gap that can be addressed with a new technology or product. Enthusiasm all by itself may not be given much of a role here, but arguably it doesn't need one; the business value it produces speaks for itself. Of course, this requires a rapport between engineering and the business that may be rare in practice.
As others have mentioned, enthusiastic engineers who feel like their enthusiasm is discouraged or shut down may leave for greener pastures. 20% time, internal tools that can tolerate some amount of churn/instability more readily than other projects, etc can all help provide outlets if they're not to be found in day-to-day work.
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.
Like you said, prioritization is complicated. There is no one way to define it.
As for enthusiasm, this is the key that would spur the developer to learn and pick up more value for the business. Without enthusiasm, the developer would stagnate and stop growing thus not being able to provide newer/better solutions to a problem.
Looking further, a developer enthusiasm could also be driven by many factors. Overall, humans are just complicated creatures with many environmental factors that could come into play.
I don't think that there is a fixed rule for this, but managers should allow their developers from time to time to freely try new stuff or technologies that they like to work on as soon as they don't affect clients' urgent deadlines, and this could also be another way for the company to keep track with the new solutions and techniques.
This way the developer will remain enthusiastic and his\her productivity might increase as well.
On the other hand developers should also try to satisfy their passion in software by themselves on the side and away from work, work's tasks are not always exciting and some might be boring and this is normal.
From my point of view enthusiasm part should be like a kitchen herbs part for a well prepared dish. If there are no kitchen herbs, that's not a big problem, but if there are too much spices, it can make things worse. Being too enthusiastic could make you exhausted too fast.
More important part is discipline, to do tedious routines/tasks to achieve the final goal.
It doesn't really come into play for me. Its pretty hard to justify to a customer that we're going to work on X first because "that's what the devs want". I think the item in question should be justified based on its own merit, not as a "we're just trying to make developers happy".
I think the issue is a lot of developers don't spend enough time trying to understand the business side. Because of this they fail to articulate the value a certain item may bring to the company.
If "enthusiasm" means "let's try the newest JS framework or this new DB" this must be heared and answered, but can not be a prio descision maker. BUT it must be answered in a good way via eg discipline meetings.
Now... What for sure must be taken very seriously is "enthusiasm" regarding solving Tech Debts. Not every Tech Debt is high prio, but if it's one which has high cost because of using expensive resources, do disturb much people (affecting overall productivity) it should get attention regarding prio definitions.