Most engineers take years to internalize this concept. Fresh out of school programmers will throw themselves at tough problems, get 80% of it done using the latest popular framework before they want to move on. The problem is, the remaining 20% is often what will drive success or failure.
As a CTO/manager/team lead, your objective is to mitigate things; keep things interesting enough while getting things done.
This usually means avoiding over-engineering, leaving some room for the team to pick the tools/technology they want (as long as they understand they will assume its maintenance) and making progress visible (celebrating milestones, having regular stand-ups...).
And even then, people will leave (some programmers can't get the remaining 20% done), shitty code will creep in and have to be maintained, and you will occasionally have to deal with legacy stacks. And that's fine.
If you call it quits because you don't want to get your hands dirty, I'm not sure I want you on my team.
I spun my wheels for the first half of my stint at a tech company by being the sort of full-stack developer who never really specialized in anything. During that time, I frequently noted that the engineers who were promoted to the top were specialists in one or more areas important to that company's goals. My managers always told me I was mistaken about that.
So eventually I specialized in one of those areas and got promoted myself during the 2nd half, so much so that Google poached me (that didn't end well, but that's another story). These days, I work amongst the full-stack crowd who want everything written in Python so they can modify supposedly low-level inner loops with impunity. When repeatedly confronted with a C or GPU procedure that is 50-100x faster than its Python equivalent (dynamic typing in inner loops is a harsh mistress and even numpy can make Python coders do really strange things leaving one with code still 5-10x slower than bespoke C/GPU code), they complain about the difficulty of writing C/GPU code rather than consider the performance they're leaving on the table and the money they're wasting by running performance-sensitive code that way.
But then, I've always considered getting my hands dirty and rooting out bizarro bugs the fun part. The hardest part for me is when to say a project is done because I can always find room for improvement. And I prefer to work with people who have a similar viewpoint. It's not easy to find them.
Its very much the case that new engineers want to work on the hardest projects and prove that they are capable and deserve lots of money and/or responsibility. But management typically doesn't care if you completed 99% of the hardest project on the block if it doesn't yield a usable result (nor should they). Its generally better to solve a simpler problem well enough to at least claim success. The downside is that if everyone feels that way, the quality of the framework for future tasks is not robust and technical debt racks up. Without a sound framework, there isn't reliable infrastructure and navigating previously written tools can't be trusted by glancing at a method or package name. It turns a depth 1 BFS into an unbounded DFS and eventually it becomes extremely time consuming to get anything done. The problem gets compounded if there is a lengthy review process and the reviewer is safer doing nothing, letting the change languish until a manager pushes for it.
As a CTO/manager/team lead, your objective is to mitigate things; keep things interesting enough while getting things done.
This usually means avoiding over-engineering, leaving some room for the team to pick the tools/technology they want (as long as they understand they will assume its maintenance) and making progress visible (celebrating milestones, having regular stand-ups...).
And even then, people will leave (some programmers can't get the remaining 20% done), shitty code will creep in and have to be maintained, and you will occasionally have to deal with legacy stacks. And that's fine.
If you call it quits because you don't want to get your hands dirty, I'm not sure I want you on my team.