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

131–139 of 139 posts

Re: Thriving on the Technical Leadership Path

#131

Post by tytso »

erobbins wrote: post #117
tytso wrote: post #71

Earlier quoted context omitted.

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.

The biggest projects span such a wide number of teams and/or departments and/or product areas (product areas at Google are headed by Senior VP's) that you're never going to have someone with the formal authority having either the time or the technical knowledge to run those projects. Even at the department level, the VP will have hundreds or thousands of people reporting to her, and so she's not going to have the time or attention either.

So the authority gets delegated down to the technical leaders, and while it can happen that there will be conflicts that have to be escalated to the VP or SVP level, it's usually because a team simply doesn't have bandwidth to satisfy a request, or are being given conflicting signals as to the prioritization of different projects, and so we need to escalate to senior management to either get more head count, or agreement that a given prioritization will mean that the project will slip, etc.

The technical leaders make the technical decisions, and are responsible for the technical decisions. Management makes the resourcing decisions, and product managers make the product decisions. Usually, it's pretty obvious whose domain a particular decision is in, and as a senior technical leader, I actually know enough about the constraints that I can tee up the question, with the tradeoffs, and then say, "but that's a product-level decision: do we ship with now, or do we slip and so we can add this particular critical feature? Note to management: if you don't like the velocity of the development, we badly need at least 3 more head count by next quarter or we will be presenting you with more Hobson's choices like this."

And that's fine with me; I don't find working with recruiters and negotiating with the CFO for headcount, or sitting in an all day meeting trying to divide up the headcount granted to the department to the various teams. Not having to do that is not "lacking muscle", it's being freed from work that I don't like to do.

Re: Thriving on the Technical Leadership Path

#132

Post by tytso »

sabujp wrote: post #121
foobarian wrote: post #120

Earlier quoted context omitted.

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

I don't know, did Theodore Tso implement /dev/random? (hint: he's the famous EXT4 guy)

Yes, I'm the /dev/random guy as well as the ext4 guy. I've also been the serial driver guy, and the tty guy (Posix job control was my first large contribution to Linux). I also was on the board of the FSG when we hired Jim Zemlin, and when the FSG merged with the OSDL to form the Linux Foundation. I was the Kerberos v5 TL at MIT, and I served as one of the IPSEC working group chairs and on the IETF Security Area Directorate. Oh, and for a while I was Treasurer for Usenix.

See? There are plenty of ways to be a technical leader without being on the management track. :-)

Re: Thriving on the Technical Leadership Path

#133

Post by tytso »

nilkn wrote: post #80
pm90 wrote: post #72

Earlier quoted context omitted.

I think your view is seriously constrained by the assumption that you can't have both a manager and a senior IC on a team. You need both to be successful. Every team I've worked in that had success had both. In these cases, the manager relies on the team, and the IC to get a clear understanding of the root of problems. You don't need to be super technically proficient to understand constraints, but understanding why…

I'm not sure if you're actually disagreeing with me. Of course a team needs a technical lead who is likely a senior engineer. I think that much is obvious. However, that person is predominantly concerned with their own team's technology. As an engineering director, I have an entire organization of teams I'm personally accountable for, and I have to make sure the work that's being planned out meshes well with what all…

The primary disconnect on this larger thread is a disagreement about terms. Does an "IC" mean someone who doesn't have any direct reports? What does it mean to be an "engineering manager"? Are staff, senior staff, distinguished engineers, et. al, without any direct reports part of "engineering management"?

The other big disconnect is in the size of companies in question. At the larger companies, you can have a clear separation of roles, so that some people are almost exclusively managing resources, and trying to match resourcing to business objectives, while other people are much more exclusively focusing on technical issues and how they can achieve business objectives by making the right technical decisions.

In these larger companies, the issue of people on "The Technical Track" not having the "muscle" of people in management is really not true, or at least, heavily over-simplified. (And this is another definitions question; at IBM and Google, Staff, Senior Staff, Principal, DE, Fellow, etc., were all considered as on the Technical track and were considered very senior engineers. Yes, they generally aren't coding much by the time they hit that level; although you might be surprised how much Fellows are still coding.)

Re: Thriving on the Technical Leadership Path

#134

Post by inerte »

oarabbus_ wrote: post #99
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…

Would love to hear some examples of experts decreasing complexity and advanced engineers increasing complexity.

There's Juicero https://blog.bolt.io/juicero/

Re: Thriving on the Technical Leadership Path

#135

Post by kthejoker2 »

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,…

The book is certainly better thsn her resume. It is very thoughtfully written, on an extremely important subject that otherwise only has folk wisdom and anecdata to look towards.

Re: Thriving on the Technical Leadership Path

#136

Post by arnarbi »

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.

You're right, that's what it usually means. But gp was asking about it in the context of this comment: https://news.ycombinator.com/item?id=21377401

Here it's being used to contrast with both TL-ship and management.

Re: Thriving on the Technical Leadership Path

#137

Post by yitchelle »

jdauriemma wrote: post #39

I'm happy for the author, but did anyone else notice a lack of takeaways for the reader? It reads like a list of accomplishments rather than genuine advice for thriving in technical leadership.

In her closing sentences, she did say "In the coming weeks, I’ll post about how to build strategy and technical leadership skills with the goal of deliberately cultivating a long-term career as an engineer."

I guess you need to stay tune for her next blog post.

Re: Thriving on the Technical Leadership Path

#138

Post by jdauriemma »

yitchelle wrote: post #137
jdauriemma wrote: post #39

I'm happy for the author, but did anyone else notice a lack of takeaways for the reader? It reads like a list of accomplishments rather than genuine advice for thriving in technical leadership.

In her closing sentences, she did say "In the coming weeks, I’ll post about how to build strategy and technical leadership skills with the goal of deliberately cultivating a long-term career as an engineer." I guess you need to stay tune for her next blog post.

Yeah, I read the article. If the takeaway is "read the next article for the thing you clicked on this article for," that seems like the author is squandering the reader's time.

Re: Thriving on the Technical Leadership Path

#139

Post by techslave »

marcinzm wrote: post #24

Being a technical leader is a set of skills that is distinct from being a great IC and those skills overlap management in many ways (meetings, dealing with people, diffusing conflict, getting buy in, etc.). Except you don't have resources to leverage directly except your own, now very limited, time so everything is 10x harder. I was in that boat, eventually I got tired and just got into management.

perhaps (perhaps!) you weren’t a good technical leader after all. the JD you put out there isn’t quite right. you do have other people to leverage...that is your job. you just don’t have hard authority over them. it’s challenging and you can’t get by on pure tech ability anymore. so many very very strong tech folks fail here because they don’t have the soft leadership skills.

your company and your boss have to support you (eg by not micromanaging, so that you can actually effect soft leadership), but the way you put it, failure is a foregone conclusion.

Post reply on HN