Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thriving on the Technical Leadership Path

keavy.com

Post reply on HN
Print view View original

111–120 of 139 posts

Re: Thriving on the Technical Leadership Path

#111

Post by pkd »

knightofmars wrote: post #74
mi100hael wrote: post #47

The Manager's Path by Camille Fournier does a good job covering the various steps from technical individual contributor all the way up through the ranks of management and looks at questions like when to stop getting involved in technical decision making. Would recommend for anyone interested in pursuing a leadership role.

The Fakespot stats on this book and the critical comments in the Amazon listing don't put this book in the same light as you have. Additionally, the conditions surrounding the exit of Camille Fournier and three other C-level individuals from the company which she was a CTO don't inspire confidence that this is good material with regards to the area it is supposed to cover. "It is a significant exodus in a short time,…

Having personally read this book, I can add another anecdotal data point to the "it's great" category. It is an insightful book without being preachy and has something useful for people at all levels. Obviously it's mostly based on one person's experience, but there's so much trash in this category of tech books that this read like a breath of fresh air.

Re: Thriving on the Technical Leadership Path

#112

Post by heavenlyhash »

xxpor wrote: post #60
arnarbi wrote: post #45

Earlier quoted context omitted.

Individual contributor, i.e. a non-leadership role

A non-managerial role* If you're a senior IC and you're not exhibiting leadership in some way you're probably not going to be around for very long.

I agree with this and thus often find the term "IC" itself unfortunately prone to being misleading.

Re: Thriving on the Technical Leadership Path

#113

Post by rzzzt »

MarkMMullin wrote: post #97
baron_harkonnen wrote: post #19

Earlier quoted context omitted.

My experience has been that the value of very senior technical staff is not that they solve "extremely high level" technical problems but they are very easily able to see how what appears to be a complex problem is isomorphic to a much simpler, easy to solve problem. The difference between expert and advanced/intermediate technical staff is that the advanced engineer has an understanding of complex solution and mista…

Much of the last 2 decades of my career has been as much principal work as I can get, and everything I know says you smacked this ball out of the park. First, if the title is real, then the term Principal carries serious weight, and hews as closely as possible to the best definitions of Principal Investigator (yah, academia has been busy making a mess of that) More often than not, a good PI knows that all problems do…

Solving NP problems every day.

Re: Thriving on the Technical Leadership Path

#114

Post by lifeisstillgood »

I am a great believer in "Software Literacy" - that software is a new form of literacy that we as society will need to ensure is as wide spread as normal literacy.

And I find more and more that using this as a lens solves lots of these sort of conundrums

What do we do with senior / principal engineers? can be translated to "what shall we do with these really good readers and writers we have hired"? The answer is not invent some parallel path in the company to have them walk around looking for solutions - they become leaders of the organisation ... or they go out.

And as for the C-suite. No CEO ever announced that "well I used to read and write but I don't have time for that anymore. I do enable my skip levels to do more reading and writing on their 20% projects however. Sometimes I dream of taking a week off in order to write something - maybe an email, like the good old days"

If the management of the organisation is spending less than half its time coding, the company does not have enough automation and will get its arse kicked by 2030

Re: Thriving on the Technical Leadership Path

#115

Post by Spooky23 »

vkou wrote: post #79
pm90 wrote: post #70

Earlier quoted context omitted.

This is an excellent point. About 80% of the time, this is how it plays out in most larger orgs. The interesting thing is what happens in mid size to smaller companies, where organization structures are not as well defined. You still need people here, however, if you know the stack very well or are a proficient IC, you can make contributions that can have a significant impact on the org, and gain the trust and allegi…

You're not making a great case for senior ICs being impactful. I mean, what you described is one way to deliver senior-level impact for a team. However, this has a very important problem. Every time you join a team, you have to build up this rapport from scratch. If you switch jobs every few years, you'll find half your professional time consisting of busting your ass to build up rapport, only to have to start from z…

Not necessarily. Positional power is only one aspect of a managers capability.

It doesn’t prevent you from using personal power and influence, although most organizations are setup to purposefully make it difficult to function that way.

Usually your best managers do both. Think of the best people that you’ve worked for in any environment. Usually they are people from whom you’d seek advice and counsel.

Re: Thriving on the Technical Leadership Path

#116

Post by wil421 »

dominotw wrote: post #3

This is bad advice. If you are hitting 40's, please do yourself a favor and go into management. Yes coding is fun but, 1. Not being able to change jobs because you can't invert a binary tree in 20 secs in leetcode hazing, is not fun. 2. Being managed by someone a decade younger than you with no family or responsibilities, is not fun. 3. Spending your weekends learning the latest JS framework because you don't want to…

I hear a lot about people having a younger boss but I think that’s more of a HN bubble. Maybe at some startups but the majority of places I’ve worked at or been to have older people as managers and they all have experience.

Once time I interviewed at a place with a few managers that were in their late 20s. Turns out they were the senior employees only having been there less than 2 years. Turnover was less than 6 months, I passed on the job and my schoolmate was there 5 months. The place had a bad reputation.

Re: Thriving on the Technical Leadership Path

#117

Post by erobbins »

tytso wrote: post #71
dominotw wrote: post #3

This is bad advice. If you are hitting 40's, please do yourself a favor and go into management. Yes coding is fun but, 1. Not being able to change jobs because you can't invert a binary tree in 20 secs in leetcode hazing, is not fun. 2. Being managed by someone a decade younger than you with no family or responsibilities, is not fun. 3. Spending your weekends learning the latest JS framework because you don't want to…

This is definitely not true. There are IC tracks at many companies. I'm over 50, still doing technical work, and I'm having a lot of fun. I was a STSM (Senior Technical Staff Member) at IBM and I'm now a Senior Staff Engineer at Google. Yes, most senior technical folks don't actually spend much time coding; it's things like technical architecture, creating slide decks for the VP's, meeting customers, etc. That was de…

> And when I say lead, very often you may not have formal hierarchical power over the people that you need to influence; but instead of you have to pursuade them to share your vision and go along with your plan.

This is the worst part of the whole gig frankly. It's an awful place to be, all the responsibility and expectations but none of the muscle.

Re: Thriving on the Technical Leadership Path

#118

Post by chrisweekly »

homonculus1 wrote: post #23
chrisweekly wrote: post #11

Earlier quoted context omitted.

IME (21-yr career), there's a huge range wrt culture, power structure, and growth oppty across different kinds of companies. The biggest / most relevant diff rel to technical path is btwn orgs that are engineering-driven vs product-driven (except when said product is in a highly technical domain). Maybe obvious, sharing in case it's not.

Are you paying your ISP per vowel or sth?

Heh, just typing on my phone in a hurry

Re: Thriving on the Technical Leadership Path

#119

Post by foobarian »

saberience wrote: post #101
nilkn wrote: post #100

Earlier quoted context omitted.

A hypothetical example would be one person spending a week or two setting up an extensive in-house Spark cluster to solve a problem that a second person in one day realizes can be solved on one machine using some clever shell scripting tricks. The former person knows a lot and may have been fully capable of the solution the second came up with, but they followed the wrong guiding principles in analyzing the problem a…

You could answer that example problem just by being someone who reads Hackernews a bunch, since the "replace spark cluster with random unix tools" article appears here regularly. IMO, that doesn't really define being a principal engineer, it's basic.

Principal engineer: arrives at company, notices expensive Spark cluster, replaces with one server running shell scripts

Double digit-strong data science team: speechless

Re: Thriving on the Technical Leadership Path

#120

Post by foobarian »

tytso wrote: post #71
dominotw wrote: post #3

This is bad advice. If you are hitting 40's, please do yourself a favor and go into management. Yes coding is fun but, 1. Not being able to change jobs because you can't invert a binary tree in 20 secs in leetcode hazing, is not fun. 2. Being managed by someone a decade younger than you with no family or responsibilities, is not fun. 3. Spending your weekends learning the latest JS framework because you don't want to…

This is definitely not true. There are IC tracks at many companies. I'm over 50, still doing technical work, and I'm having a lot of fun. I was a STSM (Senior Technical Staff Member) at IBM and I'm now a Senior Staff Engineer at Google. Yes, most senior technical folks don't actually spend much time coding; it's things like technical architecture, creating slide decks for the VP's, meeting customers, etc. That was de…

Are you the /dev/random guy? If so thank you for all the countless times I copied it as skeleton kernel /dev code. :-)
Post reply on HN