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

81–90 of 139 posts

Re: Thriving on the Technical Leadership Path

#81

Post by jrochkind1 »

arethuza wrote: post #25
jrochkind1 wrote: post #7

Earlier quoted context omitted.

In my early 40s, I am starting to reluctantly wonder if this is true after all. I don't like it, but that doesn't necessarily mean it's not true. Another point is: In many/most actual organizations, it's the people managers making strategic technical decisions, not anyone on any other track.

"it's the people managers making strategic technical decisions" I'm 54 and I'm pleased to say that I've never worked anywhere where that was the general rule - I've always been on the "technical leadership" side of things (CTO/Head of Architecture) since my 20s and I pretty much see my job as ensuring that "strategic technical decisions" get made in the right way.

I'm jealous. I don't think your experience is typical.

Re: Thriving on the Technical Leadership Path

#82

Post by LordHumungous »

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…

> You just tell people what to do, and they will build it.

That's a pretty simplistic idea of how a manager wields influence imo.

Re: Thriving on the Technical Leadership Path

#83

Post by LordHumungous »

taurath wrote: post #8

My problem in the senior IC track at my company is that of how to influence people to get things done. Managers can very easily utilize resources, where the IC has to convince people and then also horse trade on priorities between managers who usually own a certain area and can’t really spare much help. Strike teams seem to the most effective thing for ICs to lead, and having that be an explicit part of eng culture a…

You need to pair up with a good manager in my experience.

Re: Thriving on the Technical Leadership Path

#84

Post by bluGill »

ryandrake wrote: post #66
arethuza wrote: post #25

Earlier quoted context omitted.

"it's the people managers making strategic technical decisions" I'm 54 and I'm pleased to say that I've never worked anywhere where that was the general rule - I've always been on the "technical leadership" side of things (CTO/Head of Architecture) since my 20s and I pretty much see my job as ensuring that "strategic technical decisions" get made in the right way.

As CTO, did you have direct reports? If so, you were a people manager and: > "it's the people managers making strategic technical decisions" ...was true in your case. In my experience (over 2 decades now, wow I can’t believe it) the people making the broad, strategic decisions and influencing outside of their orgs all happen to also have direct reports and usually those reports are people managers too. They have titl…

The obvious influence belongs to the managers at all levels. ICs have less obvious roles, but good managers look to their ICs for guidance on what decisions to make. Thus there is a lot of indirect authority in the roles that seem to have no power - for the IC that learns to use it.

Re: Thriving on the Technical Leadership Path

#85

Post by LordHumungous »

this_na_hipster wrote: post #69

This is a problem I have thought about over my career. The TLDR; You definitely need senior level engineers (Principal's & Above) as a career track in a healthy organization. Here is why - (for the sake of discussion, "principals" refers to principals and above) - In an org, lets say as a director, I find I rely on my principal engineers to objectively tell me what the right thing to do is. They have less political m…

Yep. Well said. People making snide comments about "CRUD apps" probably don't work at scale.

Re: Thriving on the Technical Leadership Path

#86

Post by pm90 »

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…

> 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 zero at the next job.

Not half, all of your time will be busting your ass building up rapport.

Lets look at the alternative: you start a greenfield project with no understanding of what the rest of the company's stack looks like. Engineers know some person was hired to do something, and they may be interested in what you're doing, but they're probably not invested in it (the people who hired you are probably more invested, but they're unlikely to be the ones who have a deep understanding of the tech stack). You're facing an incredibly uphill battle here, as there are certainly going to be things that you will need assistance with (custom libraries, weird deployment frameworks, shitty deployment scripts that only one person somewhere knows how to get working etc.).

You may be a super genius, super hardworking person and be able to pull it off. For the average case, I am convinced this is a backwards way to approach the problem.

Re: Thriving on the Technical Leadership Path

#87

Post by nine_k »

nilkn wrote: post #4

In my experience, many companies legitimately don't really know what to do with very senior engineering staff. And how many distinguished engineers or principal engineers or technical fellows do you really need for your relatively straightforward technical challenges anyway? The IC track often fails to work in practice for the simple reason that technical work at an extremely high level is just not needed at many com…

There is little point to be a senior engineer in a company which us not growing, or at least seriously changing their technology.

Once the technology works well enough, and the ongoing changes can be supported by mid-level engineers, and there is no big challenges ahead, it's time to move on.

No, this is not how you grow in power and importance for 15 years within the same company. If you want that, management is your path.

Re: Thriving on the Technical Leadership Path

#88

Post by shrimpx »

nilkn wrote: post #4

In my experience, many companies legitimately don't really know what to do with very senior engineering staff. And how many distinguished engineers or principal engineers or technical fellows do you really need for your relatively straightforward technical challenges anyway? The IC track often fails to work in practice for the simple reason that technical work at an extremely high level is just not needed at many com…

I think the important point that's being missed is that super senior ICs are usually promoted for specific reasons. You're making it sound like they are a disposable commodity. But in my experience someone is super senior IC because they have proven to add key value when it was really needed and nobody else was up to the task.

Re: Thriving on the Technical Leadership Path

#89

Post by pm90 »

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…

Apologies. I see the point you're trying to make, and I agree with you.

Re: Thriving on the Technical Leadership Path

#90

Post by virgilp »

dominotw wrote: post #53
virgilp wrote: post #42

Earlier quoted context omitted.

I don't know what "hard leetcodes" look like... even in my teens I failed to solve _some_ problems. But what I can tell you is that I switched jobs less than a year ago, I was given as part of the interview process a link to solve 3 problems online in 1h30m and solved them all in 1h. Now, were they rated "hard"? I don't know, honestly. Also, 2years ago (I think) I participated in Amazon TechO(n) challenge... I was 1s…

I can say you are def an exception, most ppl get slower at these in their 40's than in their 20's. You seem to have gotten faster. For most people this knowledge tends to atrophy as they age. Maybe you are lucky enough to work at job that requires you to write algorithms from scratch ( embedded engg?). What is your theory as to why that homebrew guy wasn't able to solve simple recursion problem ?

Either bad interviewer ( focused on syntax rather than problem-solving skills), bad day, or simply this:

> people would do amazing stuff despite failing basic algorithmic tasks. That's what makes hiring decisions so hard.)

It's important to note that this doesn't mean algorithm tests are inherently broken. People who can't solve _basic_ algorithmic problems tend to be weak employees. Rejecting them screws your recall (a few would be amazing if hired) but tends to improve the precision a lot, so the trade-off is often worth it.

Post reply on HN