contractor^mgr^FTE-dev ]U.S.

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

  1. senior mgr
  2. contractor
  3. FTE-dev

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.

 

Advertisements

accumulation: contractor vs FTE #XR

XR,

You said that we contractors don’t accumulate (积累) as FTE do.

I do agree that after initial 2Y of tough learning, some FTE could reap the monetary rewards whereas consultants are often obliged, due to contract, to leave the team. (Although there are long-term contracts, they don’t always work out as promised.)

Here’s my experience in GS for 2.5Y. My later months had much lower “bandwidth” tension i.e. the later months required less learning and figure-things-out. Less stress, fewer negative feedbacks, less worry about my own competence, more confidence , more in-control because more familiar with the local system. If my compensation had become 150k I would say that money amounts to “reaping the reward”. In reality, the monetary accumulation was an empty promise.

As a developer stays longer, the accumulation in terms of his value-add to the team is natural and likely [1]. Managers like to point out that after a FTE stays in the team for 2Y her competence, her design, her solutions, her suggestions, her value-add per year grows higher every year. If her initial value-add to the company can be quantified as $100k, every year it grows by 30%. Alas, that doesn’t always translate to compensation.

That’s accumulation in personal income. How about accumulation in tech skill? Staying in one system usually means less exposure to other, or newer, technologies. Some developers prefer to be shielded from newer technologies. I embrace them. I feel my technical accumulation is higher when I keep moving from company to company.

[1] There are exceptions. About 5% of the old timers are, in my view, organization /dead-weights/. Their value-add doesn’t grow and is routinely surpassed within a year by bright new joiners. Often company can’t let them go due to political, legal or ethical reasons.

You said IV questions change over time so much (ignoring the superficial changes) that the IV skills we acquire today is useless in 5Y and we have to again learn new IV skills. This is not intuitive to me. Please give one typical example if you can without a lot of explaining (I understand your time constraints). I guess you mean technology churn? If I prepare for a noSQL or big data interview, then I will probably face technology churn.

On the other hand, in my experience, many interview topics remain ever-green including some hard topics — algorithms (classic algos and creative algos), classic data structures, concurrency, java OO, pass-by reference/value, SQL, unix commands, TCP/UDP sockets, garbage collection, asynchronous/synchronous concepts, pub/sub, producer/consumer, thread pool concepts… In the same vein, most coding tests are similar to 10 yeas ago when I first received them. So the study of these topics do accumulate to some extent.

managers(more than techies)need boss’s like

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.

Grandpa’s advice

  1. since you clearly know you are not good a management, don’t ever compare with the high-flyers (and invite the self-hate).
  2. know the many people who are less fortunate.

less pressure to move up in U.S.^SG

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

stay long->move up to hands-off roles: hurts fitness

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.

%%tech leadership? a few pathways

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
* javascript front-end + server side
* nosql to replace the RDBMS
* MOM-based

worked harder as FTE than contractor@@

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.

tech mgr^functional mgr

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 struggle with existing codebase

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.