- 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)
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.
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.
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! :)
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.
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.
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.
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.
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.
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.
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.
* 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.
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)
