Live data from Hacker News

Thriving on the Technical Leadership Path

keavy.com

91–100 of 139 posts

Re: Thriving on the Technical Leadership Path

#91

I don’t see why there is a technical vs management path at many companies, you want management to be a support for the product that’s being delivered and your teams should be skilled in and embody the product they’re making first. Management for management sake makes the product a 2nd goal otherwise. You could argue we can’t find people who can do that, fair enough, but there are plenty of companies that do and their…

There is more than technical situations in focus here. Someone needs to understand the financials and decide if the company can afford to develop a new product, and if so how much to spend. Someone needs to deal with the employee who is harassing a coworker. Someone needs to sell the product. Someone needs to figure out what feature is most important in the new product. Someone needs to figure out if you buy supplies at today's low prices or wait. Someone needs to decide how much quality to sacrifice for lower prices. Someone needs to decide if reusing some subsystem will pay off in the long run.

Some of the above decisions have a technical part, but none are entirely technical questions.

Re: Thriving on the Technical Leadership Path

#92
post #79

Earlier quoted context omitted.

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.

It is a gross over-simplification - but I've had a lot of managers, and not once have I seen one bust their ass for a year, and then take six months to gather feedback and peer support on their work, in order to get the rapport necessary to do the job they were hired to do.

I mean, they do this sort of thing, in order to show that they are superstar, and should get 2x the headcount they currently have, but they don't actually need to spend a year and a half convincing people with results, in order to be allowed to direct their existing headcount as they see fit.

A senior IC, on the other hand, needs to personally prove themselves at every workplace, before they are allowed to act in the role of a senior. You're expected to deliver the results of a manager, without the corresponding power. You're expected to exercise soft power, and you're expected to acquire this soft power on your own.

It is an incredibly inefficient way of getting stuff done, if you ever switch jobs.

Re: Thriving on the Technical Leadership Path

#93
post #32

She's coming from Github/Microsoft. That is a very different environment than most of us. A company of that size has more money to pay people who live outside the regular product org and more opportunities to do "strike teams". The bullet point list of strategic work that she provides mostly overlaps with what engineering managers do. It's valid to point out that you don't need people reporting to you to do it. It's…

[deleted]

Re: Thriving on the Technical Leadership Path

#94
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…

OK, let me offer the competing viewpoint. I've been a technical manager, I've been an architect, I've been a programmer and everything in between. I've run my own company outside of the tech space too. I've been around.

>>1. Not being able to change jobs because you can't invert a binary tree in 20 secs in leetcode hazing, is not fun.

This is true. This doesn't bother me though. I don't need to find "this" job, I just need to find a job. You ask me to invert a binary tree, don't worry. I'll find a job someplace else, and you can find someone else that has less experience and knowledge than me.

>>2. Being managed by someone a decade younger than you with no family or responsibilities, is not fun.

Don't honestly care. If you're a manager and making decisions on your lifestyle and feel that everyone else should live like you...see previous answer.

>>3. Spending your weekends learning the latest JS framework because you don't want to be someone "who doesn't keep up", is not fun.

Honestly, I don't have to. The foundations are the foundations are the foundations. Do I know how to use the equivalent of Redux in Vue.js? Admittedly, no I don't. I can google that. I may spend sometime looking up new stuff on my own, because I find it fun, but this doesn't stress me out. I can figure it out. You don't hire me as a framework jockey. That's not what I do. You want me to go up against some younger person who spends his time learning React and can tell you the syntax off the top of his head. OK, fine. Call me when your database has scalability issues, or your web server is overloaded.

>>4. Being paid less than the lowest grade manager, is not fun.

Yes, we'd all like to make more money. Here's the thing. I make enough money to live the way I want to. To think that all senior developers can become managers is a joke. Management is an entirely different skill set, and news flash, it's hard. Like really hard. The best manager understands things like accounting and finance. You have to keep track of head counts, who gets what raises, why do they get them. If I give this person a raise and not as much to this other person, will someone leave? How does that affect my staff. Do you understand how to counsel people, because whether you like it or not, you're going to do that too. You are a people person, you get to hear all the things that go wrong, and sometimes you need to understand how to fix them and other times you need to just listen, and you have to know when to do both. Are you ready to put your job on the line when you find out that another manager, or someone above you is sexually/discriminating or harassing people? You get to do that too (blah blah, laws against that. They can do that. Get back to me in the unemployment line on that.). Have we talked about firing people? How many people have you fired before? Not a fun requirement. How many people have you laid off that are perfectly good at their job, because the company wants to hit their bottom line? Managers may make more money than me ... when they're working. Just think how many managers vs engineers there are in the workforce. Let that sync in. You're competing against a lot of people that are or want to be managers for maybe what a 10th of the spots. Competition is a lot stronger, and that's assuming the open positions aren't been filled by people from within.

>>5. And be honest with yourself, do you really need 20 yrs of coding experience to write CRUD apps? What exactly are you bringing to the table.

What am I bringing to the table? That's easy, 20+ years of coding experience. I've seen enough to know you shouldn't do things a certain way, or a whole range of problems that people who just started out didn't even know existed. I know which log files to look in on a web server when there is a de-serialization issue. I know that a particular linker embeds a date stamp 60 bytes into the header of an assembly. I also know how to write and communicate technical problems to an audience in a simple way to allow them understand the const benefit analysis of a particular approach. You don't pay me to write code. You pay me to solve problems, especially ones you didn't even know you had. Some of them are coding problems, a lot of them are not.

EDIT: Formatting

Re: Thriving on the Technical Leadership Path

#95

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.

"CRUD" apps not at scale definitely have their challenges too. Resolving UI/UX/Requirements and pleasing different types of customers with one interface isn't easy.

Re: Thriving on the Technical Leadership Path

#96
post #61
post #13

Earlier quoted context omitted.

> Spending your weekends learning the latest JS framework because you don't want to be someone "who doesn't keep up", is not fun. It's not about JS frameworks, but if you don't keep up with technology _because it's fun_; and you also what to be promoted very high on the ladder (aren't happy with "just" an average job with average pay that lets you have a decent life outside work) by all means do yourself a favor and…

>> because you can't invert a binary tree in 20 secs in leetcode > It's a simple recursion. why wouldn't I be able to do it? I fully expect to solve algorithms & data structures questions into my 60s faster than the average 20yo can (because of my background. Point is, it doesn't correlate with age, if you can't do it at 40 you probably weren't great at it at 20). My main problem is that I look like an idiot while wr…

I never would claim that your algorithmic skills define you as a professional - on the contrary with age I got worse at contest-style coding while getting generally better (I believe) at the trade. It's just that my experience is that the companies would generally require pretty basic stuff.

On your points,it sounds more like bad interviews if they're about syntax, not about the logic.

Re: Thriving on the Technical Leadership Path

#97
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…

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 don't need the most powerful solution, some just need to go away. If a claimed principal is always applying the most complex solution everywhere, then they're bad at their job.

A good 1/3rd of my benefit is not going 'zomg - a hard problem' to my co-workers, its the exact opposite. And even when it is a hard problem, at least half the time then it's 'Don't worry - here's what Djikstra/whomever did to solve it'

I love advanced algorithms, and relish the chance to actually go try and make ones - that said, my main value is not that, its that some horrible new problem erupts, my job is to say, 'no, calm down. That's an old problem in a new suit'

That said, switch isomorphic to homomorphic - I'll give the seniors credit, they usually tag the isomorphic cases . :-)

Re: Thriving on the Technical Leadership Path

#98
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…

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…

Something that explains this quite well (IMO) is the Dreyfus model of skill acquisition. You’re essentially talking about the difference between a proficient engineer and an expert, but I also think you’re suggesting there’s a 6th level: mastery.

The beauty of the model, to me, is in the separation of skills. Being an expert programmer doesn’t make you an expert in mentoring, or leadership, or architecture sometimes, and if the place you work has any flexibility with its career setup, there’s plenty of opportunity to branch out once you think you’ve maxed out your current tech tree.

... or you quit and get paid more elsewhere/go consulting/whatever ...

Re: Thriving on the Technical Leadership Path

#99
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…

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.

Re: Thriving on the Technical Leadership Path

#100

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.

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 and arrived at a solution of considerable complexity.

An alternate formulation of this would involve the second person above arriving at a new job, observing that they're using Spark on an expensive cluster to regularly perform a computation, and noticing that actually they could do the whole calculation on a single node using simpler tools.

Post reply on HN