I either do low value work or, most of the time, I support others.

For the juniors on the team, I make myself available for pairing so I can help train them. For the seniors, I help them by writing documentation, reviewing their work and making sure it's aligned with where we want to go (you can call it architecture but I don't like to throw that word around), or help out by resolving disagreements. Or whatever they need really. Not all of that stuff is technically "code", but to me it's not primarily about writing code myself, it's about being constantly in touch with the code base in some fashion or another.

I also delegate organisational work to those on the team interested in it - I very rarely run a meeting or drive some work, I just fill in the cracks where nobody else wants to do it.

The main trick is probably that we maintain a highly asynchronous communication culture - which is not for everybody and non trivial to establish and keep. But if it works, it really works.

I really like this approach - in some respects I think managers should be serving their subordinates. I've just recently become a manager of a data team, having previously been a data person myself. I find myself with very little time to do anything technical, and envy my team members when I see them doing technical work.

Do you have any advice for a technical person newly turned manager? Anything you wish someone had told you when you started as a manager / leader?

Well, I'm thinking about trying consulting so I started to offer free consultations to get better at it - see my profile.

I can't think of a lot of generic advise: Sure, people I've talked to over the last 13 months of doing this face more or less the same problems, but how to best deal with them depends entirely on their situation, the people they work with and their own personality and skills.

One of the most eye opening things I've learned about is Cynefin from Dave (!) Snowden - wish someone had told me about it when I just started.

On the more generic side, I think the most important thing I wish someone told me is to not be _too_ humble, to trust my intuition and experience and be proud of my brand of management, not apologetic for not doing things the way somebody else read they're supposed to be done. Depending on your personality, I might as well recommend to be _more_ humble though - the balance is key for me.

> I think managers should be serving their subordinates

This is totally what I think about managers of technical staff (and not "in some respects"). It's the subordinates that are doing the production; managers are lubricant, whose task is to ensure the production staff are maximally effective. Without effective management, production staff operate at reduced efficiency. But without production staff, managers are completely useless, and might as well be re-tasked to work as coffee boys.

I'm referring to line-managers, not the executives who make business decisions. I know nothing of executive work, and I suspect there's not a lot of continuity between line management and executive work. And yet some line-managers carry on as if they're already three-star generals.

Oh, and for when I was running a larger ship with multiple teams, I would just focus on one team at a time, do all of the above there (with the other half of my time dedicated to more high level company wide work), then switch teams after a few months.

Probably not the best way to do it, and it might not scale beyond 230 people (since I never tried), but it's what I ended up with and it works well for me.

> I'm hesitant to take on technical work lest I block someone else.

Not the person that you replied to, but I would suggest doing code reviews as a non-approver, taking non-critical path tasks (documentation can always be improved) and writing examples/tests if appropriate for your system.

As a "senior" engineer, I believe it is my responsibility to code review as much as possible. It's the best use of my advanced knowledge outside of doing the occasional complex tasks.

As a manager, I would see my main job to, in this order 1) keep as much of the non-coding tasks off my ppl's plates, 2) code review when needed, 3) type actual code, 4) remember birthdays.

i don't like ppl with power over my employment and salary doing code reviews.

I had a CTO once doing random code reviews without knowing complete context. It was hard to contradict him or much easier to just accept the suggestion and move on.