Hacker News new | past | comments | ask | show | jobs | submit login

You should work for a tech company (i.e. those companies that solely focus on tech). Most usually have clear career paths for those who want to become senior individual contributors vs. managers, because that is actually very useful.

I'm skeptical about dual-track organizations (read my other post in this thread, here: https://news.ycombinator.com/item?id=8481680 ). I agree that it's a good idea, but they tend to make it astronomically harder to be a Director-equivalent engineer than a Director. Ultimately, the management ladder is easier to scale and therefore "better", insofar as you can be a Director and still code (if you want).

I look at it this way. I've been programming for 10 years and, in a typical "do what I'm told" job, I'm not going to learn anything new. Sure, managers only get 10-15 hours of coding time, but that's more than you'll get in useful coding time as a managed employee anyway.

As a manager, you can have your underlings explore new technologies and report back, keeping you current on the field, and while you'll only get 10-15 hours of coding time (unless you work 40+) you have a lot more freedom in deciding what you code, and power to get your work noticed. I'd rather have 10 hours per week of quality coding experience than 40 hours in the Java mines maintaining someone's VibratorFactoryVisitorSingleton.

Managers are good at complain-bragging and making their track sound more painful than it actually is. The fact is that a manager who keeps his coding skill current is highly valued. Being a manager means you have organizational credibility, and if you want to use that credibility to code because you think it's the right thing for you, then you can.

If I were to take a cynical view of dual-track organizations, I'd say that the real purpose is to convince the programmers that the management-ladder people are better than they actually are. A Director-equivalent programmer at Google (Principal Engineer) is an objectively strong engineer, and it's competitive as hell to get to that rank. The Director-level managers at Google aren't any better than middle-management at other companies.

The tech world is going flat, which has a lot to do with the experiences of your former employer. In this new (but not really that new) model, the hierarchy is flatter, people managers are fewer and have lots of reports, while experienced/skilled individual contributors (ICs) are expected to provide more of the leadership missing from the fewer managers (who are better at providing that anyways). When each manager has 20 reports, you don't need many of them. Even Microsoft is moving this way, and has always focused on a lot of strong ICs; distinguished engineer is a partner level position (I think).

I would be quite surprised if the real product direction power wasn't held by the principal engineers at Google. I mean, ya, the managers get to manage, and they provide some leadership, but they have those pesky management tasks and politics (all necessary) getting in the way of that. In that situation, there are also probably plenty of managers who have to manage peers (i.e. people who have equal or even more influence in the company), and the concept of "underling who reports back" is a bit of a stretch!

Look at how many distinguished engineers, or other very high level individual contributors who have actual real power there are compared to Directors and VP's who manage large groups of people.

The individual contributor path is exponentially more difficult to climb. I argue that you both have to win the lottery with the right projects and get in early at a company, and have all of the necessary skills.

I believe it is a story that is told to individual contributors by people with real power to keep them motivated.

The only theory that I've heard of where a flat org could be actually beneficial to individual contributors is the parents theory on open allocation. Otherwise it's just management kicking out the ladder once they've climbed it.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact