[bluGill]

Your best employees should always be working on the least important projects. Thus they will seem like coasters.

By making the best be on unimportant projects you get the following benefits:

Nobody worries about interrupting them if they have a problem - who cares if you make the unimportant project take more time.

Your second best people get to experience leading important projects and thus you grow them into the best people (sometimes the previous best people may need to take a turn leading, other times the third best get promoted). See above about asking questions - the best people can mentor them as needed - again nobody cares if it makes their project late.

Unimportant projects sometimes turn into next years most important project - and your best people have been creating a good base to throw lots of people at.

When sales/marketing discovers an sudden opportunity that needs people now - you have experienced engineers to take it over without killing progress on what was the most important project. (be careful about this one - if they only rarely have such requests it is fine, but if such requests take up too much time you probably should either have a dedicated department of engineers for this - with a real budget and management to ensure the requests are really valuable enough to be worth the time - or you need to tell sales not to make such promises)

[ashtar]

This is a great way to lose your best people. Or it's pure /s

[bluGill]

Not if handled right. Remember those unimportant projects are often self-assigned as try the latest thing to see if it is useful to us, and they often get high visibility to management as cool things we want to do next.

Of course if this is only treated as unimportant projects they will leave.

[pmmck]

Maybe a better term would be "critical projects" instead of "important projects" in that case?