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! :)
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.
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 :)
I'm a relatively new engineering manager in an older company in Canada (turning itself into fin/insurance tech), and a big part of my role has been about breaking down silos.
The silos where created at a time when being really efficient at 'your piece' was what the system rewarded, whereas now we want to be efficient at shipping code, which means efficient value streams (from inception to production)...which has basically meant many rounds of silo deconstruction.
But I'd be VERY curious about why silos get built in the first place & what incentives are in place to make this happen...and why this is bad. To be honest, maybe I'm just idealistic, but I see silo building as not desirable.
Not OP, but imo the classic thought is that your managerial influence is directly correlated with the count and quality of employees under you. In this sense, silos get built not quite for specialization, but because your individual managerial incentive is to try to grow you and yours at the expense of (internal) competitors for a fixed budget; interoperation can be a direct threat to your influence and growth.
A famous study of behavior like this might be Kodak, and how internally the film "silo" crushed the digital "silo".
For the background and how things go wrong, you might enjoy the book "Confronting Managerialism" by Spender and Locke. The Lean folks also have a lot of good critiques. A book that sticks in my mind is "Simple Excellence: Organizing and Aligning the Management Team in a Lean Transformation", but there are a bunch. And for software specifically, Mary Poppendieck's work is great, as well as Reinertsen's "Principles of Product Development Flow".
The truth is, in my experience, people in the major cities (and even some outside them) in the USA are the most highly compensated people on Earth. Canada and the EU have a lot of social systems that cost a lot of money. They have a lot of worker protections. This means it costs more to hire someone there and it is very difficult to get rid of them meaning more risk for the company. Because of this (and other reasons I'm sure) the wages are far lower.
In the low end and even mid-tier this probably works out better for Canada and the EU. But at the high end, which these jobs are, you're paying a large price compared to the USA. But hopefully you find the costs worth it.
Canada doesn’t have anywhere near the worker protections of the EU. It’s not quite “at will” employment but...
I live in Canada and work remotely for a US tech company which has helped keep my comp competitive. It not about laws or taxes really (ours aren’t much more than California really), it’s that the wage inflation / talent war hasn’t quite made it up here yet.
Seconded, I don't think it has anything to do with Canada's social programs. And it's pretty easy to fire someone, you just have to give them a small amount of severance depending on how long they've worked for you. I think the biggest factor is that it's much, much easier to import workers from Europe and Asia. I worked at a major tech company in Canada and the office was 50%+ foreign nationals who wouldn't have had authorization to work in the US anyway. A lot of the Canadian citizens eventually left to take 2-3x salaries in the States (there is a visa category that makes it really easy for Canadian engineers to work in the US.)
True. But Toronto is pretty bad too. And we generally don't have the high levels of stock compensation. That looks like it could make a huge difference.
It doesn't only show Bay Area numbers, though, but also e.g. Seattle, where the prices (while still high) are far lower - especially in more remote places that still have a decent commute to tech campuses in Redmond, Kirkland and Bellevue.
Would be nice if people from Toronto would enter more data points for the more popular startups I.e. shopify, instacart, unata, ritual, league, top hat, wealthsimple, freshbooks, pivotal, ada, etc
>People will move to cities and use roads less if cities are affordable. If we can lower rent in the city, automobile usage will go down on its own. This is where the fight should be pointed I believe.
This. So much.
Affordable housing and reasonable transit that makes the entire city and neighboring suburbs accessible will reduce car usage.
I work in Toronto and commute from a nearby suburb. Rent and real estate costs in the city are ridiculous, but I'm planning on making the move anyway.
I would love to live car-free, but the reality is a failure of transit. Transit sucks:
1) Transit in suburbia sucks. A lot of routes are every 30 or 60 minutes.
2) Transit between the suburbs and the city sucks. The systems are not aligned well and when you have layers of busses and trains that only come every 30-60 minutes, it just adds a lot of unnecessary waiting time to your commute. This causes a lot of people to drive and park at the GO station so they can take a train into the city.
3) Transit in Toronto is great if you happen to live and work on a Subway line. If not, good luck - you'll likely add 20-60 minutes to your transit commute. A car makes the rest of the city easily accessible.
So dealing with 2-3 different transit systems makes a commute unreasonable. If you're commuting from a nearby suburb, it can take 2+ hours to get to work.
My partner works in another suburb, and to transit there would take about 2.5-3 hours each direction. It's just not practical.
We've reached a compromise: We have a single car, and we car-pool to a reasonable spot and I take the train into the city. I'm lucky in that my place of work is near a subway stop, so my entire commute in this way is about 75-90 minutes each-way. I often work on the train on my way to work.
I'm planning on moving to the city, but we will never be able to be car-free with the state of transit the way it is. My partner will have to drive from Toronto to her work. Without traffic, probably 25 minutes. With traffic, closer to an hour. But that beats the 2.5-3 hours (each way) that it would take to commute via transit.
Toronto seems to be a city that never got around to planning a transportation system for it's massive growth. Every time I visit I'm surprised by how much further the skyscrapers creep down the QEW towards Hamilton. Even the suburban hubs like Mississauga have bigger downtowns than many North American cities.
But the transit system seems to be built for a Toronto half the size. In between the hubs of density are miles of big box plazas, McMansions and 10 lane roads with neverending traffic jams. Downtown exploded while the subways and Gardiner choked. In the race to develop it seems no one was looking at the big picture of how all this growth was going to interact.
The book is much more polished. You follow along with this repo [1]. Every chapter you simply `$ git checkout chapter-n` and you're ready to go. It's amazing.
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! :)