How my first job on Wall Street as a programmer trained me to get shit done

Many moons ago, I was a bright-eyed programmer in his first job. I worked at a major bulge-bracket investment bank. I was an “Analyst/ Developer” working for a Derivatives trading desk, building and maintaining software.

While the specifics of what I learned about Derivatives, Risk, etc. are enough to warrant a series of posts of their own- I am writing today about what I have carried over from there in terms of communication.

My erstwhile employer was an amazing place, with brilliant people and a great sense of humor. This was coupled well with a seriousness of purpose, a low fault-tolerance and a sense of urgency, given our team was supporting a trading desk. I’ll describe our culture for messaging, email and phone, timings, and how it drove productivity and a get-shit-done attitude.

Messaging

We had a tool that we used internally called YAMS- this stood for Yet Another Messaging System. I was told that there were AMS, MS, and other incarnations before, but YAMS stuck around, and I hear it’s used even today. YAMS was the precursor to the Slack of today, with many concepts carrying over. It didn’t have the slickness of Slack, but we weren’t solving for slickness anyway, and this was 2001.

YAMS had rooms that you could join- there were rooms for each function, business, location, etc. For example, we had one for Commodities Technologists, Commodities Strategists (Quants), Commodities Traders, Commodities Sales-people, etc. And there were others, not necessarily business oriented (ala Random in Slack) like one for all Strategists, one for just London Strategists, one for all Technologists. The urban legend went that back in the day, the gatekeeper of some of these made you promise that you would agree not be offended, and not to share what you saw in these rooms.

The functional ones were used for business, and we had automated feeds posting statuses, vacation days for the team, people asking for support, and general business discussions. In the more technical ones, bugs were reported, discussed and resolved, and ideas were sought for difficult problems. Think a combination of Stack Overflow, Reddit, and Cron.

After growing up on YAMS, Slack seems to take the torch forward really well. It creates the same atmosphere of transparency, easy discussion, quick responses and resolutions, and some tomfoolery.

We had some protocols that we stuck to and there was a list of commonly used YAMS terms and abbreviations that you were introduced to as part of your induction, and you learned to use them. Some of these, if used well, create just the right amount of naming and shaming, to keep people on their toes, and not just throw every query to Slack, without doing any research themselves. I’ll reproduce them here as best as I can, and would request my old comrades to suggest more in comments. I’ll keep updating the post as they come by.

• owy- oops wrong yams
• read only yams? — this has been mentioned in the discussion before. Why did you not read before posting?
• Queen Vic Dead? — reporting old news, are we?
• ytmbyts- you tell me, buddy, you’re the strategist
• imho- In my humble opinion
• imo- in my opinion
• wd
• what do you think?

The crown jewel was a list that was maintained called “Strat Hall Of Fame Quotes” and there were some true gems in there. While many were business sensitive or would be embarrassing to some, I will reproduce one from memory

What is the best owy

<Initials redacted to protect the guilty> I searched for mustachioed women. What did you search for?

I was lucky enough to watch this happen in real time. For some reason (I choose not to speculate) two colleagues were somehow discussing facial hair, and this was in one of the non-business YAMS rooms, and hence it was kosher. The conversation evolved in a certain direction, and they were both doing some google searches and discussing the results. However, my colleague inadvertently posted the final comment in the other YAMS room, which was the most popular YAMS room and was read by every developer and strategist in the company. The rest, as we say, is history.

Email

As I mentioned, my team supported traders. It was taught to us early that every minute a trader had to deal with a system problem, he/she was losing money. Perhaps we were a little oversold on this, but better to have more urgency than less when dealing working in a business where millions of dollars can be made or lost in a matter of seconds.

We had a distribution list that our client teams (traders, sales, strategists, controllers, operations and few others) would email, and we had to handle all queries. Even today, I can honestly say that my first team was the single most concentrated group of the highest quality individuals I’ve ever had the pleasure of knowing. Each one had productivity levels that I still struggle to reach, 15 years later.

On an average day, our team would receive 1,000–1,500 emails and the person on the support was expected to have read and appropriately actioned each of those in a timely manner. Within the first few months, we organized ourselves into a rotation, and for a certain quantum of time (I want to say a week, but maybe it was more) a person would be the buck-stopper. This meant that this person’s responsibility was to read and take ownership of every email that came through on their watch. They would action whenever they could, and only if there was something critical and time-sensitive and they were working on something else critical and time-sensitive, they would call upon someone else in the team to take over that one task.

What this eventually led to, is a habit of reading every email that comes through, automated or not, and action it same day. Whether I was buck-stopper or not, I got into the habit and I try to carry it to this day. I chuckle when people complain of receiving 25 or 50 emails in a day, and complain about not being able to keep up. Being thrown into the deep end at the very beginning of my career, set me up on great habits when it comes to email.

The overall expectation on email (not just support) was this: EVERY email you receive (not the automated ones) needs a response in a maximum of 24 hours. The response might be that I’ll respond in a day, or a week or a month, or I can’t help you. But NO email can go unanswered for more than 24 hours.

While I’m getting a little sloppy now, and don’t always achieve Inbox Zero (we didn’t call it Inbox Zero then, but that was the concept we imbibed), I am almost always on top of any business email that needs a response.

Here are the rules of engagement we used for emails:

1. Constantly monitor mails sent to distribution list- Outlook is great for this. Rules would send all emails to a folder and folder would highlight in Outlook showing number of unread messages.
2. Take each unread email, and reply all indicating that you’re on it. Most common message was: “Looking”- this is when email goes to Read status, so you know its off the queue, and either you or someone needs to be looking at it.
3. Quickly assess criticality and time to resolve. If criticality is highest, or time to resolve is low, handle it, and reply all with relevant update, or just saying “Fixed”- remember this was a technology team, and these were usually tech issues.
4. If it requires work, get going on it. In case you’re already on something with equal criticality, pass it on to a team-mate- but do this sparingly. The idea was that the buck-stopper is not just accountable for assigning but also completing, so that the rest of the team can focus on their day-jobs. If your support leaks over to others, productivity of the team comes down.
5. Keep track of what’s assigned to others outside the team, where the onus lies on you to update status to the person/ persons reporting the problem. If its farmed out within the team, the onus would pass to the person taking over.
6. Repeat.
7. Don’t go home till everything is done. If you *really* have to, hand over open issues to Asia teams when they come in, but try to get your shit done on your own as much as possible.

Phone

I’ll cover this section with an anecdote that happened in my first year, that taught me that its ok to be pushy/ impolite/ aggressive when you need to get things done.

For a project I was working on, I had to coordinate with someone in a different team, and for some reason, they either weren’t too interested in helping or didn’t have the time. I don’t know which, and it doesn’t matter.

In our team’s status update meeting, my team lead asked the status of my project. I replied that the person I needed to work with was unreachable. My manager’s response was to ask me:

How many unreturned voice-mails have you left for <Person> in the last 24 hours? Talk to me when the answer is more than 10.

Timings

Small point but a powerful one. Going back to June 2001, I was a newly minted programmer in his first job. Not used to waking up early, and not really adjusted to work culture yet. I used to stroll in at 9.15, then 9.30, and sometimes 10 am. I would stay in the office until 8 pm or beyond fairly often, but in hindsight, this (start time) wasn’t ideal. To set the context, the trading desk we supported started work at 7 am, and usually wrapped up by 5 pm. But our Operations and Finance counterparts stayed till later, often 8 pm, 9 pm, sometimes later. The expectation was a ten hour day. You could do 9am-7pm, 8am-6pm, 7am-5pm.

Some of our team was there bright and early, but I and some of my other recently joined colleagues would usually fall into the 9.15–9.30 bunch. Our manager would occasionally say something, but not too strongly. She knew that when we had work, we were often there till 9 pm, and occasionally till well past midnight.

One day, she just sent a short email. I’m paraphrasing, but it captures the salient points:

Its 9 am and where are my teams? Traders start at 7 am, rest of the teams start no later than 9 am. There’s no reason for our team to not be here by 9 am at the latest.

It wasn’t strongly worded, wasn’t followed by a reprimand or anything, but it really hit home. I decided that if I’m in a support role, I’d better be there when my stakeholders were. I slowly started shifting to an 8am-6pm day, and eventually edging closer to a 7am-5pm day. It’s not easy, since no matter when you start, something pulls you in and you often end up staying until 7 pm. But on the days you get done and can leave at 5pm-you can have a life on weekdays and not just on weekends. New York is great for things to do, and I learned to enjoy it and make time to do things on the weekdays too when I could.

From then on, I can’t say I’ve never been late- I’ve been late a lot- but I’ve learned to feel guilty, and it pressurizes me to minimize the lateness, or avoid it altogether. Today, if I find myself in a position in building an organization from scratch, I’d push very hard to have a work-day that starts early and ends early. I find the typical Indian culture of a 10am-8pm or often Noon-10pm work-day very non-ideal.

All in all, great productivity comes from great culture. Many parts of culture can get ingrained as habits, and am glad to have developed some of these good habits early in my career. Overall, I feel fortunate to have learned from the best on both culture and productivity.

Watch for Part 2: How Wall Street trained me to be a Full-Stack Developer, Product Manager, Scrum Master, Agile Coach, and many more things I didn’t even know existed.