There's plenty of questions where I feel like I'm having good answers to. Software design, how to prioritize things, how to resolve conflicts, all the essentials of engineering management. The bigger the teams get that I'm responsible for, the more I'm wondering to what degree I should, and to what degree I actually must be hands-on - in order to be able to effectively lead a team.
Before I dive into my struggle of the day, I'd like to preface by saying that I generally do not believe in engineering leadership that is non-technical. I think you have to be familiar, sometimes intimately so, with the ins and outs of what your team is working on - and dealing with. While that certainly doesn't mean that you can only be effective if you're spending half the time working on and in the same environment as your team, some exposure is not nice to have - it's necessary. The opposite would be the only rely on the signals you're getting from the folks, and while you'll always want to be closely in touch with those, your own judgement needs to be built on your own first hand experience.
Back to the original question I keep thinking about. There's certainly no black or white answer, so the point I'd like to begin with is by looking at good reasons for being hands-on, and what the idea behind those good reasons is.
My first reason is to actually get a feeling. Getting a feeling for how easy (or hard) it is to work on a ticket or an issue is a great indicator on how well the overall system works. It's of course just one of many indicators, but building an impression from deep diving is incredibly valuable - especially when you're able to compare that to a plethora of previous projects.
That's not only a technical perspective - there's so much you can learn by trying to get something to production. Is it easy, is it hard? What's the process, and how does it feel like from an engineers perspective? Extremely valuable insights, right there - insights that can help make better decisions.
Another good reason is to understand what's going on. Jira boards, 1:1s and feature preparation meetings and docs are one part of the story - the commits and PRs flowing through a codebase are the other part. By having a closer look into what's actually flowing into the codebase, there's often a different perspective that's otherwise harder to get. Are there a lot of small PRs without planned work? Late night work that might otherwise not be too obvious? While I generally do not use metrics like number of contributions to judge anyone's performance, there's important data points that can be derived from the frequency, nature and quality of contributions. That's a very valuable source of information - one that shouldn't be discounted.
Now, being hands-on requires at least a solid level of understanding of the stack at hand, so there's some necessary investment there. Don't go crazy, but don't stay too shallow - just enough to make it work. I always find it to be super educational to spend time with my team on learning how they work - not only from a technical perspective, but for also building more deep connections.
So, those are my good reasons for staying hands-on, and there's a theme here - hands-on enough to understand, relate and be able to address the challenges the team is facing, as well as understanding how the team is actually working.
Keep in mind that this is one of many data points. And it's probably not the most important one.