> ...let the developers choose the work...

This is much better advice than the whole article.

The article seems to be conveying vaguely that developers want advancement, interesting problems, etc. The problem with this phrasing is that it makes a manager think about placation strategies.

The root cause of the above is just poor tasking. If a senior developer says things need attention and keeps getting ignored, then how senior is the developer, really?

The advancement, engagement, product ownership, etc. all grow from a culture where strategic technical priorities aren't ultimately valued.

This looks like boredom or angst about "career progression" but you don't solve the problem by adding whiz-bang tech (gratuitous ML) or meaningless job titles.

I work at a company where developers choose the work. It's complete pandemonium. Nobody is listening to the product managers, the technical leads are doing customer interviews, the incompetent senior engineers have created a terrible mess for everyone else to deal with (and then moved on to new projects to create another terrible mess). The biggest issue is that engineers, especially ICs, absolutely are not giving a shit about anything except their own work, AND they are the only ones with any modicum of authority.

The people with any standards at all only stay ~2 years or less at a place like this.

> I work at a company where developers choose the work.

I meant that as part of professional development, technical leaders should have increasing say over the tasking of themselves and the team they're helping lead. There's lots of room to innovate and experiment on exactly how that works.

I'm thinking on the level of:

- If we haven't deprecated these old machines in 18 months, we're wasting piles of money

- This legacy code is too complex, but it will take some time to remove, so we need to start now

- Given the revenue numbers and the amount of maintenance effort we put into it, this part of the system and these features need to be removed. Let's split off a scrum of three for about a month to do it.

"Let the devs choose the work" would seem to naturally imply that they must also complete and maintain their work. That would curb the tendencies you describe.

How do you handle boring unglamorous but important tasks?

Enthusiastic(and authentic) recognition. Everyone knows those tasks suck but you can still use it as an opportunity to re-enforce how critical they can be and give a big kudos for whoever rolled up their sleeves and dived in.

Another nice upside of this approach is it helps re-enforce a culture of doing the right thing because we ship and don't just write code.

I think group recognition works excellently. Especially in terms of ensuring folks who didn't choose the ugly tasks recognize that they won't have to do them now thanks to John / Jane.

Many people, especially developers, specifically hate group recognition. People who like group recognition are the easiest to support (if they’re actually good), but sadly, these folks are the least likely to actually enjoy maintenance work; enjoying group approval correlates with a desire to work on the Big Cool Sexy New, which maintenance work decidedly is not.

You have to know your people, and give them support that motivates them. But that takes (gasp!) good managers.

I'm curious, how do you get from people who enjoy group recognition are the least likely to enjoy maintenance work?

My gut is that it goes the other way around. People who desire to work on the Big Cool Sexy New are often less motivated by peers, and more by personal drive, as by definition most of their peers won't know what the hell BCSN even is. Unless the person in question is working in a 100% BCSN shop, in which case there's likely to be fewer maintenance tasks in the first place as the codebase will be fresher.

If a project is "important" then it should have business value.

For some developers (including me), working on projects with significant business value is the definition of glamorous. Since there's significant business value, then you should be rewarding people for delivering that value (with bonuses and raises).

If the task does not have significant business value, it's probably not actually important. A lot of maintenance tasks actually fall in this bucket.

Yeah, that's what I was getting at.

I want to work on what's most important for the business and our users. Having engineers pick whatever they find fun to work on sounds broken, but I'm also interested in if and how that can be made to work.

Not all engineers are driven by "fun." Some certainly are, but I know many who prefer to work on projects with tangible business value.

Bonuses. Whoever works on this pile get's an extra $5000 at the end of every quarter. You only have to work on this pile for 6 months unless you volunteer for more.

Companies tend to try everything except the obvious: more money.

Stuck on patching up legacy software right now, project has been dragging for four months already and the next years worth of projects in the pipeline are all just as shitty. Definitely enough to make me bored, definitely enough to make me buff up my resume in case any offers come along... even $5000 would go a long way in making me feel like what I'm doing isn't such an endless slog.

Same for the last few jobs but I'm contracting which takes the sting out of it somewhat. I've still had to bail early a couple of times because it was such a Sisyphean grind that the money wasn't worth the toll on my mental health.

You pay your employees enough that they stay and do it. Ultimately, this is the only recognition that matters.

People all have different values. There's work others don't find interesting that I can be happy doing. What I need is freedom, not just for technical choices but also for process.

Praise and recognition for stepping up to the plate and taking one for the team.

It might not work for everyone or every team, but it sometimes works for me.

What do you think Juniors are for?

I fend generally "unglamorous but important tasks" are too difficult for most juniors and requires massive amounts of handholding.

Also I find it better to deploy juniors to glamorous tasks wherever possible. They benefit from the glamour to become self sufficient non-juniors.

Apologies, my comment was tongue in cheek but I agree anyway.

You assign it. Everyone knows that there's going to be some of that; that's why it's called "work". But you have to make sure to spread it around as best you can, so that one person isn't constantly being bombarded with the crappy tasks. Maybe after they're done, give them first choice of other tasks.

Indeed. There someone that is perceived worse than being assigned menial/boring work: when your manager doesn't even want to assign it, fearing losing "cool points".

This. And the negative corollary: if you always chose the rad work, and leave your devs the menial work, you're gonna have a bad time.