In the U.S. context, I feel the FTE developer position is, on average, least appealing, though some do earn a lot such as some quant developers and CS Doctor. My very rough ranking is
- senior mgr
Without bonus, the FTE-dev is often lowest. However, bonus is seldom guaranteed.
I exclude the pure quants (or physicians) as a different field from IT.
In a nutshell, compared to techies, managers depend heavily on boss relationship. Techies rely more on self-effort.
Grandpa pointed out that
- A) as an aspiring manager (at least in China), your boss’s opinion is the overriding factor;
- B) as a techie or a academic/researcher, you have the right to seek promotion based on merit and technical achievement. If you don’t get it you can try elsewhere.
I feel A) has 2 levels.
- A1) at the mid-management level, I don’t have much insight, so I guess that unlike entrepreneurs, most managers are not more capable/intelligent then other managers, so I agree boss’s opinion is the #1 factor on your career progression.
- A2) at the entry level, I actually observed many tech managers including tech leads (or architects), application owners, dev managers, support managers. I think competence level is visibly different. Some (example?) show very high technical capability. This is most relevant at the lowest level, but across the levels, technical capability is not always the #1 or #2 factor. Why?
- High-level design, technical foresight, persuasion (on tech front) are not always “innate” to these guys.
- Communication with users, team members, and manager could be equally important aspects. The Mdaq CTO singled out “listening to team members”. Not every leader is good at that.
- The most technical guy may not be a suitable leader and may be best in another role in the same team.
- Luck seems to have more impact on managerial than technical track
I think Yihai would have more to add.
- since you clearly know you are not good a management, don’t ever compare with the high-flyers (and invite the self-hate).
- know the many people who are less fortunate.
In U.S., the overall income differences between a hands-on developer vs a leadership role is smaller.
UE: U.S. engineers;
UM: U.S. managers;
SE: Sgp engineers;
SM: Sgp managers;
- salary — UE much better than SE. The few high salaries in SE are too rare and unreachable
- career longevity — UE clearly better than SE; UE probably better than SM too.
- job security — UE much better than SE due to abundance of similar jobs; UE probably better than SM
- fungible — UE can move into technical UM and back, more easily, thanks to abundance of jobs
- tech lead, architect roles — UE can move up in that direction more easily than SE, thanks to abundance of jobs. SM and UM may not have enough technical capabilities.
Economy — I feel hands-on specialists are more central to the U.S. economy and U.S. companies than in other countries. In Singapore, manager is by far the most instrumental and dominant role.
For a Chinese techie in the U.S. the prospect of managerial path is limited. Most of these managers won’t rise beyond the entry-level. And then consider your own background relative to the average Chinese here.
My tentative conclusion is
I think a few people I know said they deliberately avoided hands-off roles. Avichal, Nitin of Morgan Stanley, .. If I ever become a manager, I feel 100% sure I would adopt the same career strategy.
In the US and in Singapore, I stayed away from hands-off manager or client-facing architect/pre-sales positions. One of the top 3 justifications is to stay fit. Hands-on roles keep me fit to the job market.
In 80 to 90% of the financial IT job interviews I attended, there’s a non-trivial technical screening. However, I am an biased scientist or there’s no science here — nothing bug personal observations.
Backgrounder — (See also https://bintanvictor.wordpress.com/2016/03/03/long-term-system-expertcontractor/) I did hope to stay in a job for a few years and grow into a system expert. In a few places, it turned out that in one team (say up to 10 people), there are multiple system experts each with many years of experience in the local system. Even if you have 3 years experience in this local system, you may not be appointed the team lead. The chance is 50/50 … could be 30% or 70%. So do you want to remain here for 3 more years and hope for a leadership role?
When I couldn’t rise up in the team, I always decide to move “out” of the comfort zone into the “cold” — every job interview has a technical screening. I soon came to the conclusion that to stay relevant and marketable, I must maintain portable (non-local) tech skills. Many techies at my age wouldn’t choose this route partly because only a minority of techies can stay fit after 45.
Well, I see myself in that (lucky) minority. I don’t mean to say I’m as fit as at 30, but I am fit enough to pass the tech screening.
Many friends feel I could consider how to move up. As an experienced (I didn’t say “strong”) hands-on developer, I saw a chance to move to lead developer, architect or project manager roles when moving to Asia. It didn’t happen, for several reasons.
Now I feel by default I will remain a senior developer at VP or AVP level, and surpassed by younger competitors. Already I feel many 30-something are stronger than I am at this age, technically.
With aging and family commitment, this default pathway is weighing more heavy.
Some people (like Ken Li) believe we will be fine. My parents also feel I worry too much. However, the world is not so kind and caring. Commenting on business (not individual) competition, Andy Grove said only the paranoid survive. The default pathway might get narrower and we might find it harder to find jobs. (In Singapore I already see the telltale signs.) I feel I need to think harder how to move up. I think there are some visible pathways. See also https://bintanvictor.wordpress.com/2015/12/27/app-architect-civil-engineer-or-a-salesman-sgus/
If I have good enough know-how about certain frameworks and base products (such as spring, or MOM, or DB with embedded business logic) I could lead a team in building a few types of solution: * database-centric web apps
* batch processing of data either, in java or scripts.
There are many other types I’m less familiar with but feel confident I can pick up and lead. * mobile front-end + server side
* nosql to replace the RDBMS
My experience – in terms of work attitude, professionalism, ownership, my contractor jobs was not really lower than FTE. However, longer hours were rare. When I work longer hours as contractors, manager often recognize more easily.
Personal sacrifice was lower.
Ownership of project is often with FTE.
Expectation of bonus is real as FTE.
All in all, the bitterness (and pain, blow to self-esteem…) of a poor appraisal and low bonus is deep, hard, pervasive. It last many months and is a bigger stress than marriage issues, kids poor studies, investment failures etc. I was “shaken to core” (Michelle Obama once said) by those events.
Generally I choose to work at slightly higher than the minimum level to get by.
- as contractor — sometimes this hurts me (Citi) but often my standard is well above the manager’s
- as FTE — I don’t like to work way harder than the minimum, because often (Stirt, GS) it’s still not good enough for various reasons, so I would feel “not worth it”.
- I also have a conviction that managers decide which FTE they like based on non-technical reasons, so why bother to work so hard? If manager doesn’t like me then hard work won’t help a lot.
Most of my immediate managers are “technical managers”, aka
“specialist managers”, or “tech leads” or “development leads” — leading by doing.
The other major category of managers are “functional managers” or “generalist managers”. Examples — PM, senior managers. Lim Yanguang pointed out that the PM’s he has seen don’t have/need any specialist or product knowledge. Job duty is cost control including time-lines, resource management.
When I think about (or compare with) the “managers”, I need to distinguish these 2 types.
- Key feature — Tech managers can, if needed, write a module by himself. That means the guy must remain hands-on “forever”.
- Key feature — No one has a better grasp of the technical side of things.
- Key feature — has to read a lot of code.
- Quant team manager are always specialist managers.
- I feel Google’s managers are tech managers.
- German’s career path is a tech mgr.
- Avichal’s career path is a tech mgr.
How about product managers? Could be a specialist manager, though Some minor ones don’t really lead any team.
contract work Usually requires less of a struggle with existing codebase. Look at
* 95 Green? all interfacing with existing system is via Ravi, so no struggle at all
* volfitter? the c# codebase was not so well established and not such a struggle. The FMD sheet was a struggle but … expectation was really low.
* reo? I was transferred to BAU projects but expectation was low. * nextgen circuit model bulider – some java code was already there before I joined so I had to understand it — a struggle
In general, high rate contract is usually funded by a development project. Not so much prod support, difficulty laser surgery on a overgrown legacy codebase which require lots of local system knowledge.
Q: Look at my current per-hour value-add to the team. How many percent of that value-add is portable to next 2 jobs?
%%A: I feel it’s usually rather low. Mostly about local system knowledge.
%%A: current value-add/hour increases over the years and grows with relationship.
In the big banks, many team managers really need a owner-developer, a system expert ( …as German said) to remain with the system for 3-6 years. However, on Wall St and London, there’s a long tradition of hiring (proven) high-caliber contractors as the big guns to get through a tough project.
eg: Song Jun
eg: Rob in the Stirt tech team
Also, from budgeting point of view, a system needs a long-term owner (like BAU), whereas a project needs temporary manpower. So that’s one difference between a lead developer vs a contractor.
The owner-developer often earns more, but ownership is not guaranteed simply by staying for x years because
- there may be other old-timers
- even after 4 years some parts of the system may still be unfamiliar to you
- even after 10Y on the system, you have below 50/50 chance to build credibility and position to convince everyone to follow your suggestions. Look at Kevin’s influence after just a few years on the system.
For me, it doesn’t make sense to get very familiar with a local system and become efficient and a “powerful” local system expert. Yes the manager would appreciate my value but
- it often takes 2+ years and a lot of learning effort (Does it cause aging? Only if excessive stress.)
- Still, for many years the existing experts may remain more powerful than you, so manager may not appreciate your value as much as you expected.
- the learning effort takes away from my “body-building”
- Depending on context, it offers only 50% protection from job loss. Sadly, due to lack of body-building, you may become weaker on the new job market.
- the appreciation seldom translate to meaningful compensation