[tyleo]

I feel like a lot of leadership positions are like this. I was a Principal Tech Lead at a 300 personal company and I did everything from PMing large tech teams, to collecting info from top users in spreadsheets, to building demos directly for the CEO, to building a key part of our tech used by over 100 other engineers.

I always told people I’d plunge the toilets myself if they were preventing the staff from working. I feel like the closer you get to top leadership the more your job becomes identifying and executing on whatever is highest value that you have the skills for.

[zmmmmm]

> identifying and executing on whatever is highest value that you have the skills for

There's a hidden assumption there though, that you CAN actually do that. At least management skills mostly stick over time but even a year away from hands on technical work is going to leave you likely stranded and unable to execute on the technical aspects. Which is why I continue to push back against suggestions technical managers shouldn't be engaged hands on. Apart from being incredibly hostile to their own interests (it will be central to you getting hired to any future role), it also impairs one of the most strategic aspects of the role which can drastically affect the value you can deliver internally in the future as well.

[jjav]

> but even a year away from hands on technical work is going to leave you likely stranded and unable to execute on the technical aspects

This is an interesting myth, but certainly a myth. I guess if we consider technical skill to be intimate knowledge of the latest fad framework, that might be one source of the myth. But that's not technical skills, just trivia about an implementation detail.

The fundamentals like networking, process and memory management, databases and SQL, all change slowly and are very long-lived career-spanning knowledge.

[tyleo]

Agreed, I haven’t seen this in my career at least. I’ve worked with contractors on a yearly basis who would take some time off and then hit the ground running.

If there’s any data supporting the opposite, I’d love to see it.

[rester324]

Kubernetes is not a fad. DynamoDB and MongoDB is not a fad. Golang is not a fad. These were all born in the last few decades, so they are rather new, and they will stay for equally long decades. And the list goes on and on... So all of those skills in your list mean nothing when it comes to these fundamental technical tools. They require an understanding on a completely different abstraction level which is equally complex as of those that you listed.

So if you don't have the understanding of these technologies when the project requires it, you are obsolete and you have no right to be in a leading position. And such fundamental technologies are born continuously.

So this myth that you can have fundamentals and that's enough is definitely untrue.

[jjav]

> Kubernetes is not a fad. DynamoDB and MongoDB is not a fad. Golang is not a fad.

These are indeed good examples of things that are merely tools, not fundamental knowledge.

Time-transport me an expert C programmer from the 80s and I'll have them productive in Go in two weeks. It's all very familiar territory.

O send me a mainframe programmer from the 60s and they'll be up to speed on kubernetes in short order. Pushing your workload to a remote cloud (mainframe) won't be exactly be new to them.

Databases have been studied and their properties understood for a very long time.

Sure, the exact details vary a bit and the command line options are different, but that's not significant.

[rester324]

Yeah, that sounds logical. Some of the most popular technologies of this time are just teeny-tiny tools, but some of long obsolete technologies and their attached skills which have no correlation to anything recent is somehow fundamental and has magical properties in your view :D Thanks for the good laugh!

> Databases have been studied and their properties understood for a very long time.

No they haven't. Noone ever considered schemaless databases or column-storage databases or vector databases for half a century after the birth of computing. So that kind of knowledge (relational DBs, etc in the 60s and 80s) meant nothing in light of these new technologies, and required completely different skills and knowledge.

But it's clear you are not familiar with these technologies, so it's a waste of time to engage with you now

[roryirvine]

If people think that not being hands-on for a year is unmanageable, then we as an industry are doing something horrifically wrong.

It would mean that no engineer could ever aspire to become a parent, take a sabbatical, further their education, or experiment with alternate career paths.

But I promise you that that is not actually the case. In fact, it is often the engineers who've stifled every other part of their life that are most likely to struggle in their mid-careers and beyond.

[zmmmmm]

Yes, I don't mean actually taking time away - more organisationally, once you assume a role that is divorced from technical aspects and then try to come back to managing those without hands on experience. You will find that other more technically informed people rise up and start to become decision makers - you can't be authoritative any more and constantly have to ask someone else to give input on technical aspects since you aren't up to date with the current set of assumptions about it.

[saghm]

> I always told people I’d plunge the toilets myself if they were preventing the staff from working.

This is a lot closer to a literal interpretation of "shit rolls downhill, so a good manager will be a shit umbrella to protect their team" than I thought I'd ever see.

[camel_gopher]

You have to be careful of the perceived politics around this. Tall poppies get cut down. I still don’t totally understand why but sometimes taking initiative doesn’t sit well with the folks who want their trains to run on time.

[tyleo]

I think this varies from person-to-person or maybe organization-to-organization. I've definitely seen variations in the health of organizations but I think you can break up the categories used to judge them, e.g., meritocracy, overtime frequency, planning accuracy, psychological safety, value of work, etc.

I'd say the place I worked felt above average in meritocracy. In other words, it felt like folks sticking out to take initiative were more often rewarded than punished. I don't think we were perfect in every category though.