Don't Waste Your New Hires
I watched a newer team member spend most of their first few months entering data into a tracking system. Not because it was a learning exercise, not because it helped them understand the domain, but because the senior they were supporting didn't want to do it themselves. They weren't being developed - they were being used as a shortcut.
There's a version of this that makes sense. When someone is new, giving them straightforward, process-heavy tasks helps them learn how the team operates. They learn the codebase, the tooling, and how the team communicates. Filing tickets, updating dashboards, running through checklists - that's all reasonable when it's temporary. The problem is when temporary becomes permanent, and the newer person is still doing data entry six months in while the senior works on the interesting problems.
Newer team members need real work early, not after they've proven themselves on enough grunt tasks.
The first reason is mental stimulation. If someone was good enough to hire, the work needs to be interesting enough to keep them. If the most complex thing someone new does all week is categorize tickets or copy data between systems, they're going to check out and find a company that gives them something to think about.
The second is growth. People grow into experienced engineers by doing that level of work with support, not by sitting out while someone else does it. If you want someone who can design a system, they need to have been in the room when systems were designed - and not just as a note-taker. Give them the chance to propose a solution, get it wrong, and figure out why. That's how you end up with the experienced engineer you need in two years.
Being deliberate about what you hand them matters more than shielding them from complexity. A newer team member can own a feature end to end - scoping, implementation, testing, deployment - if you're there to course-correct when they drift. That's mentorship, not a risk.
There's a second problem I've seen that makes this harder: inconsistency across seniors.
If a newer team member works with multiple senior engineers, and each senior has their own process for how work gets handed off, how code gets reviewed, how decisions get documented, they spend half their energy just figuring out which set of rules applies today. Senior A wants a design doc before any code. Senior B wants a working prototype first. Senior C doesn't care as long as the tests pass. The newer person isn't learning engineering at that point, they're learning personalities.
The specific process matters less than having a consistent one. When a newer team member moves from working with one senior to another, they should already understand what's expected. When a senior picks up someone new, that person should already know the workflow. Consistency removes friction that has nothing to do with the actual work.
Someone who spends a year doing busywork and navigating inconsistent expectations isn't getting closer to being the experienced engineer you need, they're getting closer to leaving. And when they do, you're hiring again and wondering why new talent doesn't stick.