# 1) My GS managers have a feel about how much production support each developer is taking on. Therefore managers can monitor the learning pace of the new hire.
(Note Tier 1 or Tier 2 production support teams take on a lot, but they can’t read source code. Developer team always receive a lot of escalated prod support requests.)
Sooner or later, we realize there need to be a way to numerically measure the accumulation of _local_system_knowledge_ by the new hire. Many new hires intuitively feel “now i know close to half the systems”, or “now i have 75% of the system knowledge of my mentor”. A more objective way to measure is to simply count the number of system issues (big or small) resolved by each developer *independently*. I also count in all user questions as system issues. Together, they represent the “load” on the production support team. The more a new hire can help “offload”, the better. If a new hire is not taking on enough after 6 months, improve her training.
Crucially, only the knowledge relevant to “offloading” is true “system knowledge”. Manager needs to know the difference — a lot of know-how isn’t relevant and doesn’t constitute system knowledge.
#1b) Some of my GS managers realize that every proficient prod support person need to get their hands really dirty with logs, autosys JIL, DB investigation, tracing through java/SQL/scripts — an overwhelming body of “traces” or clues. A foundation of the “local system knowledge”.
In other banks, some new hires grow familiar with 1/3 of those traces in a year — too slow. It’s possible to achieve 70% familiarity in a year. 100% is defined as the minimum level among primary production support guys.
#1c) my GS managers asked me to spend a session each week with a system knowledge expert colleague, going through the weekly 300+ emails sent to the team. A lot of production support tasks originate in such emails. Personally, I feel any amount of such knowledge sharing can’t replace resolving an issue independently. A new hire needs to use her own head and interpret, guess, rule-out-possibilities, not just follow a cookbook. A lot of the “traces” are misleading or incorrect.
# 2 ) Perhaps the manager’s most important guide is the determination and conviction that “we can and will train this person up in 6 months to start delivering real business value”. A crude analogy — once you pay big money for a power drill before home renovation, then you want to get real value from the investment. Given this conviction, the manager makes everyone in the team aware new hire’s survival depends on their help, so “be prepared for the hundreds of questions new hire may ask”. In another bank, a senior mgr told me to reduce the volume of questions and learn to “slide into the new team”.
My GS manager spent lots of time trying to understand how I learn, how i spent my time, what questions I ask, where I often get stuck. This is what mentors do. Micro-managing? Perhaps.
3 ) My personal favorite (possibly biased opinion). Some of the new hires were put into “intensive production support” mode, kind of immersion training, spending 70% their time on prod support, far more than on green field or BAU. This lasts 3 months to almost a year.
) This is nothing special in GS — Let a new hire take ownership of a production support task and follow up till closure. I feel other banks too easily allow a new hire to pass on a “hard” problem to colleagues. In GS, New hire is encouraged to ask many “why” questions afterward, and mentor/colleagues should give in-depth answers. Both sides should be aware that some questions are less relevant and too early.
My GS managers, just as in other fast-paced banks, like to mention note taking. New hire’s note taking is frequently criticized in many banks. He can’t write down everything he hears since what he hears don’t make sense to him anyway. He can’t afford to spend too much time going into all the “why” either.
) This is nothing special in GS — Sometimes there’s a dedicated “mentor” to transfer basic system knowledge. A good mentor can make a big difference, such as pointing out the wrong things to delve into. Some new hires prefer asking many different colleagues.
I was a decent mentor. I share quick tips to set up tests, point out the tools worth learning … I spent a lot of time sitting with the new hire.
) In my GS department, people are generally more available to help or answer questions than in other companies. This extends across department boundaries. If I need help from another business division, I can send mail or call them and get immediate answers, or they will get back to me.