Saturday, May 4, 2013

mediocre Wall St developers earning Wall-St-level salary


A paradox to share with you. For years I often wonder

Q1: why does wall street (a shorthand for "world financial centers") pay something like double the salary compared to main street, for a senior programmer? (Disclaimer -- Wall St is not the only sector; premier tech firms also pay well above main street.) On many teams including my current team, I see people doing main street programming work, using main street technical skills without any financial domain knowledge. Why pay us so much higher than main street?

I feel this is a non-trivial paradox. A deeper understanding helps us manage our career, manage our competitiveness, manage our job security, manage our workload, manage our value-add.

In this letter I use "ibank" as a shorthand for all the employers in the investment-banking and security trading business, sometimes including buy-side. Yes I'm deliberately vague and imprecise.

Factor 1: ibanks have higher margin than main street, even after 2008, and crucially a small percentage of employees are responsible for the profit. Many ibank jobs are, to be honest, not critical to the money-making machinery, but many developer jobs are. To put things into perspective, traders, fund managers, deal-makers, advisors/salesmen ... are in the profit center and even more instrumental to the money-making machinery. The closer to the money, the higher is one's value to the ibank. Highest paid wall street (non-manager) tech roles are probably the high-frequency low-latency experts because they are closest to the money. Their code has a most direct impact on the competitiveness of our trading engine in the arms race. Similarly, our pricing system calculates the prices sent directly to the market and have a direct impact on our competitiveness.

Therefore, many senior programmers are considered instrumental/important for the high margin of an ibank.

Factor 2: these tasks are often fairly complex and easy to mess up, and therefore calls for expertise, backed by track record. (To be fair, these are not the most complex.) For comparison again look at the most important roles in ibank profit centers. There's usually a lot of decision-making, a huge flood of information to digest. An ibank can hire fresh graduates to create trading applications, but they are likely to fail to meet some of the requirements. In and outside Wall St, software dev is knowledge-intensive, methodical, intricate, even fragile, unlike many other jobs in finance.

Therefore ibanks generally recognize in-house app dev as high-value (sometimes instrumental/enabling) and complex. I have heard many times "we can't introduce this new instrument to the market without the IT system".

Factor 3: Just a small number of experienced coders are needed. In main street, we see armies of developers for a given project. (Lee Chong Wah may disagree.) On Wall St, team size is cut to a third or a quarter. In so many ibanks I have worked, I always see a lot of senior developers and few junior developers. I feel OCBC (and other traditional banks) see developers as the same "armies".

Therefore ibanks have high profit, and want to use part of the profit to attract a small number of elite developers. This is a "perfect storm" for higher salary. Now, in reality, a team of 3 to 7 senior developers would have just 1 key developer, so the other guys are not that critical. Perhaps one of them is doing nothing special at all. Low-value, low-importance, mundane code, but still paid well above main street. (I might be one of them now.)

Factor 4: During recruitment, ibanks typically have an adequate budget for a senior developer. If market rate is 140k, and their budget is 90k then they eventually hit the reality that strong candidates (with track record) won't be interested, so they end up scraping the bottom of the barrel. Mostly tough and unsuccessful.

So managers go get a sufficient budget, screen, select and offer to this fairly strong candidate, but for various reasons he doesn't get to play that key role. He may even end up with some truly unimportant modules, somewhat over qualified and overpaid. Managers can't just drop him, but can leave his contract (if contractor) to expire without renewing. If not a contractor, then bonus is in question. If the guy is actually good but the mundane job must be done in the team, then maybe unfair to mistreat him....

That's my answer to the opening question Q1. But there's another question, because ibank managers are not stupid....

Q2: For the non-critical roles, why don't they hire strong main street developers and pay them main street salary, to do whatever main street work there is in the project? No track record needed.

I feel many enlightened and bold ibank managers actually do that, but there's a risk of uncertainty in following that route. Instead, most managers much prefer candidates with proven track record in a similar project. Also, recruiters are reluctant to submit profiles without relevant experience. Therefore, main street developers are largely excluded from the talent pool.

1 comment:

Alejandro said...

Regarding Q2 - There are other factors to consider as well. For some insight into some of the political and "gut feeling" reasons that decisions get made talk to any experienced Headhunter. You might be surprised at some of the perspectives they can share.

Total Pageviews

my favorite topics (labels)

_fuxi (302) _misLabel (13) _orig? (3) _rm (2) _vague (2) clarified (58) cpp (39) cpp_const (22) cpp_real (76) cpp/java/c# (101) cppBig4 (54) cppSmartPtr (35) cppSTL (33) cppSTL_itr (27) cppSTL_real (26) cppTemplate (28) creditMkt (14) db (65) db_sybase (43) deepUnder (31) dotnet (20) ECN (27) econ/bank` (36) fin/sys_misc (43) finGreek (34) finReal (45) finRisk (30) finTechDesign (46) finTechMisc (32) finVol (66) FixedIncom (28) fMath (7) fMathOption (33) fMathStoch (67) forex (39) gr8IV_Q (46) GTD_skill (15) GUI_event (30) inMemDB (42) intuit_math (41) intuitFinance (57) javaMisc (68) javaServerSide (13) lambda/delegate (22) marketData (28) math (10) mathStat (55) memIssue (8) memMgmt (66) metaProgram` (6) OO_Design (84) original_content (749) polymorphic/vptr (40) productive (21) ptr/ref (48) py (28) reflect (8) script`/unix (82) socket/stream (39) subquery/join (30) subvert (13) swing/wpf (9) sysProgram` (16) thread (164) thread_CAS (15) thread_cpp (28) Thread* (22) timeSaver (80) transactional (23) tune (24) tuneDB (40) tuneLatency (30) z_ajax (9) z_algoDataStruct (41) z_arch (26) z_arch_job (27) z_automateTest (17) z_autoTrad` (19) z_bestPractice (39) z_bold (83) z_bondMath (35) z_book (18) z_boost (19) z_byRef^Val (32) z_c#GUI (43) z_c#misc (80) z_cast/convert (28) z_container (67) z_cStr/arr (39) z_Favorite* (8) z_FIX (15) z_forex (48) z_fwd_Deal (18) z_gz=job (33) z_gzBig20 (13) z_gzMgr (13) z_gzPain (20) z_gzThreat (19) z_hib (19) z_IDE (52) z_ikm (5) z_IR_misc (36) z_IRS (26) z_javaWeb (28) z_jdbc (10) z_jobFinTech (46) z_jobHunt (20) z_jobRealXp (10) z_jobStrength (15) z_jobUS^asia (27) z_letter (42) z_linq (10) z_memberHid` (11) z_MOM (54) z_nestedClass (5) z_oq (24) z_PCP (12) z_pearl (1) z_php (20) z_prodSupport (7) z_py (31) z_quant (14) z_regex (8) z_rv (38) z_skillist (48) z_slic`Problem (6) z_SOA (14) z_spring (25) z_src_code (8) z_swingMisc (50) z_swingTable (26) z_unpublish (2) z_VBA/Excel (8) z_windoz (17) z_wpfCommand (9)

About Me

New York (Time Square), NY, United States