Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Are you on a technical specialist career path, what does it look like?
56 points by tcgv on Feb 26, 2021 | hide | past | favorite | 54 comments
In the software industry we are advertised that above the Senior SW Engineer level there's a bifurcation in the career progression path (resembling the "Y" letter) and one could possible proceed to:

- A management career path

- A technical specialist career path

While there's plenty of material available on a manager's role and responsibilities, it's much harder to find a consensus on what a technical specialist role looks like.

So, are you on a technical specialist career path in you company? In case you are what are your responsibilities, and what does a typical work week look like for you?

Also, if your company provides a technical specialist career path (even if you've not reached it yet), how's it structured?

Thanks in advance!

Related discussions:

[1] On Being a Principal Engineer (https://news.ycombinator.com/item?id=19128489)

[2] What a Senior Staff Software Engineer Does (https://news.ycombinator.com/item?id=20851476)




This is often called an "architect."

I was on that path in my previous job.

First: I had to defend that path. When my manager was promoted to director, and needed someone to manage my team, he tried to covertly turn me into a manager after I declined. Fortunately, the VP of engineering intervened, but if he hadn't, I'd probably have left for a company that supported the technical specialist path.

Second: You are expected to lead in some way; you can't just do the same job that you did with 5-10 years of experience out of college. In my case, I was architect for a business critical component of the product. I designed critical path parts, reviewed other engineers designs, implemented critical path parts, reviewed other engineers code, ect. We promoted one of my co-workers to manager, and the manager and I worked very closely together, but I directly reported to the director.

2.5: Your job is no longer to "do what you're told." You need to be able to manage up and help management anticipate technical issues. You will need to push for major refactors, rewrites, protocol changes, code quality, ect.

Third: Job changes are going to take more time. No one wants to pay extra just because you have extra years of experience. Finding the match for your technical experience and career experience, with the pay premium, takes time. This mostly has to do with the learning curve of tech stacks; no one wants to pay a guy with 20 years experience in ABC stack to learn XYZ stack from the ground up. You will also have to walk away from opportunities that are just trying to hire cheap people who "do as their told."

Finally: Consider "consulting" when you change jobs. It's an easy way to leave if you don't work out in a new job. There's a lot of reasons why a job won't work out, and may of them aren't your fault. You just can't screen a company closely enough in a job interview to know if it's going to be a good match, so starting with a 3 month or 6 month contract, and not renewing it, is a good way to protect yourself when you realize that you just can't work with someone.


As an 'architect' how much resposibility do you hold for managing people/processes or mentoring/coaching "your" team? (in addition to the techinical expert/oracle, internal consultant and facilitator roles you performed).


Processes: I had a lot of input to process (and wrote a few,) but I didn't "own" them. What was more important was clearly communicating what the process needed to be, and why. Then the managers held people accountable for following the process.

Managing people: I didn't handle things like discipline, interpersonal disputes, pay, performance reviews.

Mentoring / coaching: This was mostly of a technical nature. I helped other developers become stronger developers and worked on techniques to help them move through their work more effectively. (Before you start on a new bug, look through all tickets assigned to you and ask any questions that would block you.)


In a lot of regular (non-tech) companies it's way harder to progress on the technical path vs management path. The need for very senior technical people is often not very high and there is not much of the type of work that these people could do. Most companies don't develop new databases, operating systems or cloud offerings.

A lot of them also like their managers to make at least the same money or more than the tech people reporting to them so your salary outlook is also limited.

In summary: Unless you are at a company that does very advanced technical work the technical specialist career path is often very limited in terms of advancement opportunities and salary potential.


> The need for very senior technical people is often not very high and there is not much of the type of work that these people could do.

I don't buy this. There are bizillions of technical challenges, people are waiting for any sort of relief from Covid, Climate Change and all the other - sometimes more happy - challenges of every day life. Few of these things can be solved in a purely technical way. But we rather want to work on commodity problems. This observation ironically holds true not only in Software Engineering but probably anything Tech/Science related. On the one hand there are these really obvious problems that need so many people hours and on the other hand everything slightly difficult is too risky, too expensive or just too much work.


“I don't buy this.”

I wasn’t saying this is a good thing. But in reality this is how it works. Not many companies take on very challenging technology tasks. This includes the big tech companies whose innovation output to me seems pretty low compared to their revenues and profits.


Also a lot of the experience is not transferable.


A note from a recent Engineering Manager:

I think in general, the management career path can lead to faster short-term gains in terms of career and compensation, but the most senior devs almost always have more interesting work, autonomy, and better compensation (EM's often make less than say, Staff/Principal devs).

I think "impact" is how you level up in either path:

The more senior you are, the more your work impacts larger parts of the organization. As a manager, you level up by running a team, then by running multiple teams, etc. You're a coach who's always helping your team grow & removing impediments to their work.

As a dev, there are multiple options:

- Evaluation of technologies

- Help setting best practices

- Mentoring the team / leveling up the technical skills of others

- Pair programming / answering questions / supporting team members

- Being involved in projects early on in their inception

- "Just being a solid contributor" on critical projects that need a particular level of quality or speed

For better or for worse, I don't think you can get to the most senior levels by "just putting your head down and coding". Both as a maker or a manager, you're going to have to learn the people/organization side to some extent.

The advantage of the technical route is it will often lead to more interesting projects and you still get to code! :)


"and better compensation (EM's often make less than say, Staff/Principal devs)."

this may be true in Silicon Valley but in most companies management gets compensated better than engineers no matter the level.


That is changing. Companies are starting to realize that the best technical people are harder to fire than good enough managers, and for the lower levels of management they only need good enough. Starting meaning that it is still unusual, but companies have been forced to make this change by the market.

I doubt technical people will make more than C-- level people anytime soon. Right now your quick path to more money is in management. It is now a heard of thing for someone technical to make more than their boss, but it is still the exception not the rule.


Great topic.

Yes/no. It depends. Context is king.

If we're talking VP/C-suite level compensation, probably not.

If we're talking engineering manager / director level, the answer is likely yes.

The issue is, the higher up you go, the less roles there are (for either manager or dev). It's usually way easier to jump from dev to manager than from dev to staff/principal engineer. There is also likely a cycle of having to prove yourself at new companies (often staff roles are promoted from within), but I am seeing more and more staff roles on job boards.

It's actually a great career move to jump into management for a period of time, pick up the skills, then jump back to dev. It would make your impact even higher once you become a staff engineer.

I don't know how useful this is. But if you love to code and don't want to manage people, it's a solid route.

If you want fast compensation increases in the short term, go for the management route.

Edit:

I chose the management route because I like support, basically. Helping people, solving problems, and seeing people grow is my favourite thing. You can do this as a dev, but I found that I enjoy this stuff more than coding.

I also love systems thinking (computers, people, process). So it's a good fit for me :)


This is not an absolute rule, but in general I see the path not being Y shaped but P shaped. Even if you stay technical you're going to end up managing something. Could be people, could be a process, could be creative, but your expertise is going to diverge away from writing code on a daily basis. I've been a consultant for about 12 years and even though I'm technical I still end up managing some stuff for clients.


> you're going to end up managing something

IMO, it's important to understand the line between management and leadership.

Running code reviews, making designs, reviewing other designs, evaluating architecture, picking libraries and patterns...


> Running code reviews, making designs, reviewing other designs, evaluating architecture, picking libraries and patterns...

That's got me thinking, how much managing does leadership entails? All of these activities are incredibly valuable, and indeed require technical leadership skills, but what's also challenging is to make sure they are conducted continually and in accordance to defined processes. Is that something incumbent to the technical leader? If not leadership may not "happen" unless there's a manager involved.


I agree it's an important distinction that unfortunately gets conflated at many companies. Most of my experience is in top-down big companies where leadership is a skill, not a position. Maybe when I grow up I can work at a company that makes the distinction.


Here’s a career ladder from Mozilla that’s been posted a few times:

https://pbs.twimg.com/media/DoWyoObUcAERDNk.jpg

In my experience, you start out on your team and you learn the ropes. At some point you notice your code base is a mess, application is designed poorly, your team lacks any standards, there’s no tests, bugs get shipped and outages happen, and you start speaking up. Hopefully you do this in a productive way where you have a plan for gradual improvements (ie don’t just suggest rewriting everything in Clojure), you prioritize effectively, people listen, and things improve. At some point a greenfield project comes your way and you use your past experience to make sure these issues are addressed from the get go and build a solid application with appropriate tradeoffs. Above all you need to get shit done because that’s what the business is going to care about. Hopefully you work at a place where you get at least 5 of these greenfields in different technology stacks and build some intuition on what the big tradeoffs are to be made and how they affect the bottom line. At this point you have some experience and become more valuable in discussions other people are having about their designs because you’ve been around the block a few times and know what issues they might run into. You might start designs and pass them off to be worked on. Then you might get to the point where you’re able to design a group of systems and the interfaces between them. At this point there’s usually a crossover between management and engineering because you need to have soft skills, but you also need your technical skills to be as broad as possible and sharp as hell. Otherwise people are going to notice your incompetence and you’ll get shitcanned or demoted. I’ve been on calls that got escalated to the VP of Engineering level and it just blew me away how skilled they were at stuff they probably haven’t touched in years. Hopefully you get to experience that some time and see the kind of level you need to get to. In the day to day it’s a lot of that, jumping in where needed, coding prototypes and breaking things down for junior people.

A real factor in your progress is going to be your manager and organizational structure. If you have a good manager they are going to get you more opportunities. Otherwise you’ll end up walled in on your team and your aspirations will be unfulfilled. If you feel like you haven’t progressed in a while, it’s time to look around for other opportunities.


I work for a major pharmaceutical. Effectively, there is no tech track in our IT organization. Technical advancement in IT peters out below principal scientist level. However, in our R&D division, chemists, biologists, chemical engineers, and statisticians do rise to PS level and beyond. It's a mindset: IT management doesn't value technical chops anywhere near as much as they do project management skills.

The PS role here also serves the agenda of R&D much more directly than it does in IT. In R&D, PSes act as advisors, sitting in on maybe a dozen or more projects and offering advice to minimize risk, maximize yield, and validate research techniques and initiatives. But software is perceived as serving a business need, not a technical one, even when it takes place on behalf of R&D. Input from business-side stakeholders continues throughout a project's life, but computing experts are consulted only briefly -- before the design and maintenance stages in a software lifecycle. Also, many IT advisors arise from outside the company, from vendors or external consultants.

Pharma IT's attitude has long been, "We'll follow the lead of mainstream industry trends rather than maintain in-house IT expertise." With perhaps 95% of our software arising from 3rd party apps (or mods thereof) or external services, we have chosen to let industry trends and fashions drive our IT priorities and solutions.

In the end, most pharmas believe IT is a necessary evil to be cost minimized, not an essential game changer that can help us beat the competition.


Parent post is right on the money.

Many companies talk a big talk about tech but ultimately believe it is not a core enabler of innovation, but rather a necessary but annoying cost that they haven't figured out how to minimize effectively. I've definitely seen that in the past. They're more businesses that use technology, rather than technology companies.

Often, fashion dictates their technical aesthetic more than actual taste. Which is fine, as long as they're honest about it. (And I just _feel_ someone itching to justify this point to me in a reply. Don't bother.)

Current trajectory of my career is that of a technical specialist, namely in the area of static/dynamic analysis and compilers. Basically, the science part of "computer science." Of course, not many companies do this sort of thing. That's fine. There are companies that value experts, and expertise, but they may not be the types of companies that get talked about on HN. The tech world is much bigger than HN.

I could write a book on this; I have gone all the way down the rabbit hole of burnout and back in trying to carve out my career niche. It can be done.


IF you prove them wrong, then you have just earned yourself the top technical position. However that is a big if. So long as lab work is where the company is, IT should be a lower role. In fact for some companies even if you developed the perfect software the correct answer is this isn't what we do so we will sell the division (read you - if you don't like the new company you can quit as they won't allow you a job with the old). If you don't like it find a different company.

OTOH, it isn't clear that any company actually needs another great person with the ones they already have. Be prepared to start in the middle and work up.


I would recommend you check out StaffEng [1]. It was linked here a week or two ago and I've found it quite helpful as I evaluate which path in the Y I want to take

[1] https://staffeng.com/


Consulting company. After "senior" my career stalled. An older candidate was brought in and made "lead" immediately on a project that I built from the ground up and lead. I was moved to a different project and promised architect. Did architecture. Unofficially given team lead title. Officially, all serious talk of my career is avoided.


Some consulting companies don’t want senior techies as they are largely doing commodity work that just needs to be minimally competent.

Some firms want eminence and want to have a technology competitive advantage so they develop a specialist or senior staff path with pay and equity similar to a partner or director.

When I used to work in consulting I would ask about the equity structure. This would quickly reveal if there’s only a partner path or there’s some other thought leader path. Seeing the equity and company would distinguish from firms that said they had thought leaders and who had the title and those who actually had career paths and peers other than partner.

It also helped that I figured out that consulting firms are really just engines that create partners. That’s the formula and bad firms fixate on this metric. Good firms distribute and realize that investment in senior staff is important and that just naming someone a principal engineer isn’t as important as compensating them as a principal engineer.

Every firm talked about having great people, but only some had action.

Kind of like there’s some “technology” companies where the entire C-suite is non-technical and has no tech background. Then there’s others where the c-suite includes tech and the executives were once engineers and whatnot. That shows the nature of the company more than titles.


I work at a consulting firm as a Principal Software Engineer. I do a ton of mentoring, application design, interfacing to other departments, and solving the hardest technical problems. It's mostly related to AWS cloud design/deployment as a company but I mostly do application architecture.


Thanks for the advice!


IMO: Reflect on why this happened, change jobs, and learn from your experience.


I'm a Principal Engineer at a big tech company, so I think I fit your description. But I don't think the phrase "technical specialist" applies to me. From being at a big tech company, I know of some technical specialists, that have an amazing depth of knowledge in one area. For me though, I got to where I am focusing more on knowing a little about a lot of things and being able to tie things together.

In our company, Principal Engineers (PE's) have varying responsibilities, but they usually revolve around (1) reducing ambiguity in projects and (2) proactively looking out for technical challenges that can bite the team in the long run. That can mean a lot of different things. For me, it's mostly involved writing design documents to come up with strategies for solving problems (and all that's needed to do that, such as getting iterative feedback, doing deeper dives in particular areas, reading industry or academic research, talking to people who have knowledge in more specific areas) and writing code to tackle more challenging areas. These problems are usually ones that would span multiple development teams.

The question of "transferability" that someone else brought up is interesting. At least in my career, I've jumped in to some pretty niche things that have proved in the end to be transferrable. The fact that I had experience managing a data science team before helped me get my 3rd job. A major factor in getting my 4th job came from the fact that in my 3rd job I had worked with Erlang. And my current role I got at least in part because of my experience at a telco startup. What I've found is that in any job, some stuff is completely dead-end knowledge (my domain knowledge about number porting will probably never be used again), some niche knowledge that might come up again (knowing how to do Bayesian probability analysis or write Erlang code), and some things that you'll apply over and over again (how to learn a new domain; how to work in an area where you are not an expert; how to understand customer needs; how to effectively communicate your ideas).

In any case, even if you aren't managing people, as you advance as an individual contributor, mentoring and helping other people grow will still be a large part of your responsibilities. In our company, the senior individual contributors often advise managers on how to think about the performance of individuals.


Thanks for sharing. It supports my general idea that even to progress in the "technical path" developing strong interpersonal and mentoring skills is essential.


I think the path towards Technical Fellow or equivalent is less discussed as every company needs management of humans and budgets (and the needs are relatively similar), but not every company needs the Technical Fellow type of role and those roles are more company specific I think.

What SpaceX needs for top, hardcore technical talent is very different to what Microsoft needs. An engineering director or VP could much more easily cross to the other company than a Technical Fellow could.


As someone who worked for SpaceX and Microsoft I think they are more similar than you might think. A lot of the harder persistent problems are things like managing complexity, having a good process, keeping a team running, and keeping an eye on the finer details. And those are the same. I think it's more about how you approach problems.


That’s what I was trying to get at: that management/coordination of humans tasks are much more similar across companies than deep technical tasks.

I think of those as on the branch of the Y of management, not the branch of Y of technology specialty.


There is some of each.

SpaceX needs programmers who know a lot about rocket fuel. Microsoft needs programmers who know a lot about how text editors work. The technical expert in either of them can't jump to a technical expert in the other.

Both companies also need more transferable technical experts. If you know something technical well (cmake, rust, ...) at one and the other decides to start using it, you are automatically valuable to lead best practices so they don't make a mess of it. Mostly technical people are promoted from within, but if they are all novices in something they have played with just enough to know they need to jump in, a outside expert can make the difference between success and failure.


> it's much harder to find a consensus on what a technical specialist role looks like.

IMHO that's becasue, in the companies I've worked for, the technical specialist path was really just a dead-end. That's what you would call people who you couldn't fire but had refused to move on to management.

In practice the only real way to go down that path is to set up your own consultancy, so you can work on hard problems in a very specific niche with multiple clients. That's because most "normal" companies just don't have enough hard problems to justify paying for more than a very small number of large fulltime salaries for a given skillset. I expect even in engineer-dominated FAANGs there is a lot of competition for few specialist roles.


Don't think of technical specialty as getting better with tools/processes. Think of technical specialty as getting better at solving classes of problems in a specific domain. Tools come into play and mastering them is a side effect of the problem space.

For example, I specialize in the Search domain. Most of all it involves understanding why people can't find things in most search applications, and how to fix them given myriad situations. There is a vast set of skills and tools needed to solve these problems, and I picked them up along the way in the past ~10 years I've been working on it.


It's much easier to consult, with the added benefit of (generally) being more tax efficient.

The problem is that companies rarely offer that kind of path - most often because they don't need true specialists or don't need them all the time.

Make sure a company really needs a specialist role: In some companies you'll see a fake tech specialist path being given to senior engineers who want more money or managers who were too troublesome to keep on the people side. It's not any different from normal senior contributor. The VP or CTO generally have an incentive (which often goes against the business) not to lose staff (especially senior level) as they won't necessarily be able to claim back the budget from the business and won't make them look as good as it could ("my department is bigger than yours"). Eventually results don't happen, the board gets tired, fires everyone (or create unfavourable conditions) and the corporate cycle restarts.


Other options exist. My own career progression was something like

* Coding

* Architecting – develop system frameworks with juniors filling in the detail

* Communicating with customers to understand their needs, often by sitting with them using software we had developed

* Helping the customers to write good requirements statements

* Knowing enough about the domain to identify the need for a new system, as a precursor to writing the requirements

* Helping the customers to develop business cases for new systems and explore costs and benefits of competing solutions

* Advising the customers on how they could improve their own processes by, for example, using standards rather than suffering proprietary lock-in

* Supporting customer change programmes, e.g. to change their organisation and processes to prevent creating incompatible stovepiped systems in the first place

The domain here was simulation-based military training systems (typically vehicle simulators but also simulations of the wider battlespace and C4ISR systems). The progression took place over about twenty years.


I was just offered a role as a Technical Product Owner for our Mobile Build Engineering team - I've been a software engineer for almost 10 years now, and did not think that architecture or management was for me. I'll have the opportunity to write some code still while (hopefully) having a say in the things we are building which are more technical in nature than consumer facing apps for eg. Though this is the first role like this at my company (we're Fortune 5), and I hope it works out this way in practice (things tend to look nicer on paper than in practice here).


I started out as a sysadmin getting certified in PCI compliance. After that I've moved to consulting and working on getting my CISSP and moving towards security and compliance with a systems focus. We'll see how it pans out but I appreciate the high-level view and reading contracts. I'm a terrible salesman though so finding additional gigs has been my sticking point.


From what I've seen, this kind of work involves managing technical decisions about a project or product while, to a lesser degree, managing the engineers driving that effort. There's some aspects of mentorship; at some places, traditional management duties (hiring/firing/performance management/budget) is also expected.


"traditional management duties (hiring/firing/performance management/budget) is also expected."

At my company most Fellows are basically managers. they have reports and do what managers do. Only a very few of them only do technical work.


Additional related discussion:

[n] https://news.ycombinator.com/item?id=26154095


Will Larson’s blog and now book answers this question very well:

https://staffeng.com/


i am in my early 20s and after 6 years as engineer i am starting to dislike the industry and move into product or engineering management. looking at some engineering veterans makes me depressed on the prospects on being another decade into the industry. people seem exhausted and the job now increasingly looks like a low grade clerk job. not sure if this resonates with anybody. happy to be challenged.


I am in my early 30s and after 10 years I still mostly love the job. I've dipped my toes towards management at one point and quickly felt overwhelmed and out of my depth, and realized I'm much happier when coding or discussing technical problems, explaining solutions and so on. It just feels like more useful, fulffiling work to me than updating reports, discussing timelines, people allocation etc.

Just giving my own perspective, not claiming anyone else's is wrong.


I'll code until I retire.


This definitely resonates with me as well to an extent. However, I've identified the core issue being related to where I'm working, and not so much the career itself. I'm in my early 30s, been in full stack development for the entirety of my six year career.

As another poster said, startups are tricky. I've worked for two, and the first was a poster child hostile work environment, doing subpar work for angry clients with ridiculous expectations. The second was an incredibly positive experience though the pay was junk. Now I'm at an enterprise, and burned out like I was at the first startup, but have identified a different path forward (heading into SRE now) as I know the root cause of this mentality now.

At the end of the day, if you're not interested or passionate about what you're working on, and you don't have clear upward mobility within your org, it's time to move on. Otherwise, it feels like your career stagnates and you think the career itself is the problem, not the current employment situation.


It does resonate to some extent, but I still like software.

If you dislike the industry, you might still not like product/engineering-management roles.

It seems to me like myself, you need to find out what kind of work you like, what you'd explore for your own curiosity even if you are not paid.

Trying out OS/networks/compilers/data-science/research roles might be worth your while. But, if core CS is not your thing, it's possible you will find management roles (product/engineers) more satisfying.


Where are you working? What are you working on? Who are you working with?


backend/infra from startups to big corps. especially in product driven startups, where engineers are 2nd/3rd class citizens. in consultancy, is somewhat better as it's engineering driven, but dull in the long run.


First thing is engineers are not second class citizens in any startup worth their salt. To the contrary, engineers are absolutely the most important thing, and if you can put on a bit of a product hat it's a super power that will drive not only your career success but actually impact the trajectory of the company as well.

The problem though, is anyone can start a startup, and so you need to be sure you don't fall in with bozos. If you have a 5-person startup, and someone is "Head of Product" and full of their own ideas and talking down to engineers (or otherwise making them feel as you describe) then most likely you have a bozo on your hands, perhaps due to ego inflation during years of successful hoop jumping promoted by our education system & corporate culture.

The bottom line is that product management is one of the hardest disciplines, and within tech it's filled with wannabes who schmoozed their way in but don't actually have the chops. This is not the end of the world if they are humble and willing to take input from engineering. The flip side though, is that as an engineer you need to be customer and business-centric in your thinking—not all engineers can/want to do this, but with the structured thinking the discipline requires you at least have a head start. Good luck.


> n product driven startups, where engineers are 2nd/3rd class citizens. in consultancy, is somewhat bette

The the exact opposite of my experience.


Maybe you should try FAAN where engineers are 1st class citizens.


Not sure if a typo or an intentional omission. Isn't G a "engineers-first" company?


Unfortunately, GP might have morals.


There are many different paths, what is important is you stand out on your path. You need to be stand out great to earn any more with 30 years experience as you do with 10 (inflation adjusted).

Someone else in your company on a path probably means you cannot take it (unless they are almost ready to retire, but often nobody actually takes over when someone retires), so be careful to chart your own unique path. With management a middle manager of an assembly line isn't that much different from a middle manager of a software project.

You can teach others. This is the person that decides we need to adopt a new language and figures out how to do that. You may soon find someone else is better than you at the language, but that is good because you are already working on a change culture from within so a minority doesn't feel excluded. This is a people job, you need just enough technical skill to be trusted to lead as an insider (managers are always a but outside and untrusted, while architects are too ivory tower)

The person who is in touch with the customer and figuring out what could be produced. They never write production code, just a prototype that shows things work between crashes. Maybe 5% ever gets to a real customer, but that 5% is important enough to keep them around. (Read you better have a lot of ideas, and not care that most don't get funded)

The non-manager recruiter. This person is at all the university job fairs. When they go to a technical conference you can be sure HR will get a dozen resumes in a few weeks. They know how to talk to technical people and get them excited.

The technical/manager compromise. This is the person who looks at all the technical dept and figures out what is worth investing money to fix vs just a "in a perfect world with unlimited money, but short of that there is no point. You will also be looked at when schedules and work are not lining up (with Agile this is different, but the concept exists) and figure out if/where adding people is useful. This person provides the technical input to the management decisions.

The best programmer in the company in some important/useful way. You take on the hardest programing tasks (the two hard problems in computer science: cache invalidation, naming things, and off by one errors) in the company and get them right every time.

The ISO representative: You are important to the relevant industry standards committee. ISO rules may not give you a vote, but when you object to something half of the voters switch to no.

If you have any speaking skills at all your are a regular speaker in technical conferences.

Note that with all of the above who you know is as important as what you know. They are on the same level, since you need to know enough that someone else doesn't call you out (though you can get by for 5-10 years on just who you know eventually management will change enough that you are caught). However if you don't know the right people you are back to one of the good people we have instead of the best person we have. The right people are often other technical people who then tell their manager as opposed to the managers directly. (in the best companies you are rewarded for making this two way - so tell your managers who their best junior people are)

Last, do you really want this? A lot of people are happy advancing to 10 years of experience, and then reaching their peak. They can lead their small team of engineers and go home at night. They don't spend weeks away from their family at conferences. (one a year is good, but that is enough)




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

Search: