------------
BrownMan
Strengths
Dedication - BrownMan takes it upon himself to work long hours and weekends in order to meet his project deliverables. He has demonstrated a willingness to put in whatever time is necessary for the projects he is working on.
I have worked 70hrs for 9+ Consecutive weeks including weekends and including July 4th holiday - always logging in 3-4 hours after office hours from home up to midnight or past it. It was so intense Greg even mentioned that I should take a day off when all this is over. However I do not want it. I have used my own vacation days instead. Working after hours and weekends has become a habit that I continue to do it even now just to be pro-active on work items in advance.
Knowledge Sharing - BrownMan can be counted on to share his knowledge and experience with both the new Cognizant team as well as the Market Data team. Recently, BrownMan took it upon himself to help train the Houston Market Data team to run VaR impact analyses, This has greatly reduced the amount of dependency that the Market Data team has on the VaRs BAU team freeing up VaRs resources to work on other projects. Additionally, he has provided guidance to the new Cognizant team, helping to onboard new team members.
Not only did I have a presentation session to train the Market data team I sat through 2 of their projects helping them to do VAR impact analysis and test runs. Following is the Thank You note I received for my presentation.
Subject: Had a very useful presentation/knowledge sharing session
Greg
I just wanted to let you know that we had a very useful knowledge transfer session with BrownMan today. He covered several topics and provided detailed explanations to our questions.
I am confident this session will help us to analyze the impacts of market data and the nuances of testing better.
Thanks for his time.
ps - we may circle back with more questions, when we really start testing VARS.
Thanks
Vishy Raman
713-750-3576
I had helped the GUI team on Clearcase issues helping them move their code without losing history. With regards to helping Cognizant team apart from answering questions about VARS, I have helped them on few critical occasions (Sudipta’s lost code) to migrate code from Clearcase, my background in Version control and Clearcase administration was valued on these occasions. I have helped Greg on several occasions answering his ad-hoc questions regarding Calculators, Framework and sometimes on pre-project related aspects which has enabled him to answer questions from business or upstream. This was not assigned to any project in PAR and sometimes took significant time.
Opportunities for Improvement
Ownership and Accountability - BrownMan must demonstrate the ownership and accountability necessary to ensure his projects are successful end to end. The recent EMMI Phase 2 project was a good example where understanding the process end to end would have been very beneficial and could have reduced issues. For example, BrownMan did not catch an issue with processing multiple tenors that caused a code change late in development. This change was prevalent in multiple iterations of EMMi files and should have been noticed during one of the iterations of unit tests. In this case, BrownMan needed to ensure that all records of the input feeds were being processed correctly by the VaRs code. If he is unable to verify these types of tests, then he should reach out to other team members and resources for assistance.
I believe this is a red herring. On the ownership and accountability front I have done exactly what was instructed to me by my previous manager Anna Guarnieri considering the circumstances. It seems like Greg has changing expectations and says to cover up for his failures on the same aspect of ownership and accountability.
He gives the example of EMMI. EMMI project did not have a Business Analyst during most of the development phase. There was no formal analysis phase either. Our best BA at that time, Lee Sheard, had clearly told me that EMTS system was a “black box” to him. I had repeatedly drawn attention to this fact, on a recent occasion Greg countered it saying – “Well, I don’t have 3 Lees”. On upstream end the analysis phase was done by EMMI team late last year in which I participated on a question/answer basis providing information on how various fields in the feed are being used by VARS, the analysis was done from an upstream perspective to meet their goal of generating an EMMI feed. It was NEVER intended to be an analysis document for VARS. If there was a BA on our end who would have analyzed the same from VARS side the “multiple tenors” would have jumped right of the page and easily understood. There is another important reason why Greg did not care much about the need for BA - This project was based on the premise and promise that EMMI will replace the incoming EMTS feeds as is and all that was expected from VARS was that we do technical testing of the files to make sure they get loaded. Everything else would fall in place. But as the project progressed we uncovered about 50+ issues in a span of 3 months. Issues were related not only from VARS but Stress, SNPR and PCM as well. There was no way to compare the files and know all this in advance, simply because EMMI started portraying though it’s EMTS replacement it will not be really like EMTS, in EMMI trades were aggregated unlike EMTS and they did not want to migrate all the bugs that came with EMTS feed. Everyone involved including the management was aware of this. Most of the issues were captured at some of point of time, please see attachment 1 and attachment 2.
Considering the above it turned out that VARS was used as a testing ground to verify the feed quality both in terms of format and content. While some issues turned out to be enhancements most others were flaws. Once we realized the flawed trend our request for EMMI to unit test their feed before sending to VARS did not really have the intended effect as EMMI was focused on reconciling the data to Front desk and not benchmarking it against an EMTS feed. Once we started producing VARS results there was a project manager who was assigned as BA but it was too late too little, it was almost deadline. Initially she was also lacking EMTS knowledge that we had to rely on the business user to validate our unit test results. This was a case of doing UAT equivalent testing in SIT environments with no BA to validate the test results. About reaching out to others in the team – At the time I started working on EMTS except for one developer admitting that she does not know anything more than just testing the feed nobody else in the team knew anything about EMTS at all. Another person who had enhanced EMTS and no more in the BAU team also was very wary of making any changes to EMTS code since he was unsure of what the code was intended to be doing.
Greg did not share very important information during EMMI project. After few weeks after project begins I found out through some usage of words by the upstream manager in the meeting, words like “pilot”, that there are actually 2 phases to EMMI project. No sooner I heard this I approached Greg and told him just to confirm. Greg replied – “May be, I must have forgotten”. Greg either forgot or did not understand what pilot and full go live actually meant from EMMI side. I believe this was very critical information that affected our project planning. I had to scramble to get several code aspects in place to handle this, it was akin to processing a “new” feed in addition to existing feed and process them in parallel. We were having a weekly call every Wednesday for 5 months and there was an upstream project manager asking for him always. Though he had delegated this meeting to me from VARS side it was a case of extreme delegation which cost us, If not all he could have attended some to share/interact what he knew at various junctures. Definitely he would have been able to understand the gravity of the situation first hand with feed issues discussed above and not simply blame me for all the failures. Once he expressed his displeasure about EMMI manager – “Why should I manage HIS project” after some phone talk and one other time he told me after EMMI pilot sign off was received – “Screw EMMI” – 2 clear instances that proved he did not like EMMI.
Additionally, he must be aware of changes in his environment that could impact his deliverables and be sure to coordinate with other teams that are using the MRT Production and UAT environments. In the both the CDS Idio-VaR and EMMi phase 2 projects, BrownMan missed multiple issues that should have been caught prior to UAT including:
- VaRs changes were not merged with MRI Backfeed ValSrv code changes for CDS Idio VaR.
- ValSrv changes were not correctly labeled and thus not picked up in the first CDS Idio-VaR test runs
- UAT forms and testing procedures were not coordinated with SNPR and PCM teams for CDS Idio-VaR
- Changes to Market Data jil jobs dependencies were made after BrownMan’s clearcase branch was created. BrownMan did not check for those dependencies and thus those changes were not incorporated in the original EMMi release. This caused a production issue.
Simply put, BrownMan must ensure that his projects run smoothly and do not encounter the last minute changes that have occurred on both the EMMi and Idio-VaR projects. While he has been working on 2 projects with tight timelines, he must ensure that his work is of top quality and ask for help if needed.
Since priorities keep shifting Greg has more background and information on when projects are going live. He did not share one of them sooner. On the day of UAT start for CDS Idio VAR project the ValSrv was packaged well and all set to be tested. But then he drops the line – “MRI Backfeed changes need to be part of your ValSrv”, I had no inkling of this going to come. The previous Sunday night there was a mail from one MRI Backfeed team member says “I think this has no conflict with our ValSrv” but nothing more. It’s common in VARS to run separate ValSrv before they get merged. MRI Backfeed changes had already been tested in UAT and if anyone they or Greg had better idea of when those changes are going in with what, in this case if their changes are going in with CDS Idio Var or not. Anyway as soon as he informs I got the configuration spec from others, removed my labels, merged MRI Backfeed code and built the binary. Even this did not compile on UAT end as there was another ValSrv change (RMBS) that even Greg was not aware of that needed to be merged – So I had to merge two other ValSrv changes to mine in the last minute while UAT was waiting on us.
Because of this in the rush I did not put the label back on 2 files which originally had it. This is a minor issue usually caught by Configuration management person and happens all the time but on this instance he also failed to mention it. He has to lookup the UAT form to gather all the code with a specific label and if he does not find any he responds back. That did not happen. This mistake cost us 2 days in UAT which was not entirely wasted since we discovered two other non VAR issues in that run. Considering that subsequent UAT run went on for 3 weeks, with PCM / MktData /SNPR code fixes, this matter seems highly exaggerated. 2 more weeks went by since there was a SNPR bug in legacy code before the project went live. I did not have a single code issue in UAT. The root cause was that Greg did not share the information he had which would have prevented these trivial happenings (these account for first 2 issues listed above).
About UAT forms and testing coordination it’s an additional responsibility I have taken up, but it’s not easy without cooperation from SNPR, Stress, PCM and Market data teams. For all the projects I have done so far I am the one who has collated all information that makes up most of the UAT form. I always ST and make phone calls to update/inform but haven’t received timely cooperation from others always. Other teams have their own priorities as spelled by their respective management and the message does not get across. In case of CDS Idio VAR project SNPR team was still making code changes when I was ready with the UAT form. Even on the day of UAT the form was not ready. They did not have any idea what the project is about either let alone how to test it. I was explaining them in detail on the day of UAT. The onus cannot come from VARS always when other teams have respective deliverables and equal responsibility and accountability. Whatever the reasons coordination despite being done does not elicit the desired response. I have ST evidence to prove this. Management push is required and I have used Greg whenever required. And if Greg thinks enough is not being done or achieved then he needs to step in.
About the production issue, I agree, but need to elaborate on this odd one. This was my first Production issue in 2 years with JPMC. And this happened because production support, not AD person, had introduced a dependency in a jil job, this happens very rarely, these dependencies are not identified by compilation processes. It was not a C++/script code issue. When the issue was raised to me I resolved it within half an hour after diligently working with Market data team and finding out the root cause. Proactively I informed larger development team what other jobs might be impacted because of this change introduced by production support.
All the issues highlighted by him are technically trivial, I have already stated the reasons for “last minute changes” and how they could have been avoided. Working on 2 projects was tight but never the reason for issues stated above. In fact Greg at one point gave me a choice to lighten my workload but I opted to continue to work on both projects. I had dedicated my time so much to both that I did not want to lose any credit for all the hard work that I had already put. And I really wanted to succeed.
Attention to Detail - BrownMan needs to spend time to do thorough analysis while working on a project. He missed an important piece of analysis in the CDS Idio-VaR project in that he did not notice that the VaRs conversion code was not retrieving the SPN name for certain source systems in the Instrument field. This was caught late in the project and a quick fix, that will need to be cleaned up in production, was implemented in order to meet the current project deadlines.
These statements are distorted. About the item he mentions about the CDS Idio-VaR project it was clearly a sudden expansion of project scope. Initially the BA had stated that – “Instr field was already expected to be in the XP with the SPN/UCN information”. Based on that available precondition we had several rounds of to and fro communication to arrive at a conclusion in terms of what needed to be done to get the project done. And I had given my estimate based on that premise. One day in the morning BA said it would not work for two source systems out of many. Immediately I started researching and arrived at a technically accurate solution within half a day. With this it was possible to continue work without affecting timelines. I conveyed my finding to Greg the same afternoon. Taking the classical approach would have cost us 2 to 3 weeks of additional effort in development and testing without any additional business value. He did not complain then but said we will have to clean up later. And I agreed and proceeded. I am not sure why this is misrepresented this way.
In general talking about attention to detail I can give numerous examples to support. Apart from 3-4 projects I have done so far I have done about 12 to 15 L3s. Some of the L3s I have researched in detail and have resulted in their scope being identified as projects because of the level of detail I put into research and interaction I had with business and upstream. In the course of CDS Idio VAR project I went beyond VARS scope to identify what needs to be changed for SNPR/Stress and conveyed to that team. During UAT phase when a defect was reported from UAT I fixed 3 defects on SNPR code proactively when the developer from that team was not around.
More attention to detail could have avoided the EMMi multiple tenor issue as described above as this was documented in the EMMi requirements that he helped to document.
I have already explained this above. It was EMMI specific doc and was stated in obscure comments section. It’s too important that it deserved an internal analysis document from VARS side created by a VARS BA considering how VARS was processing tenor in legacy code.
Communication - BrownMan has had issues with his communication this year. For example, he will often send cut and pastes of code to non-technical people when describing an issue. This has led to confusion and does not reflect well on BrownMan or his team.
Greg has not provided detail about this. So I have to guess from where this is coming from. I believe in cooperation and team work to get things done. As an IT person I was hired as a Software Developer primarily and not as a finance person. Finance is a secondary skill that I am constantly learning and improving upon. The situation is reversed for a BA. And when the two of us talk we try to reach a middle ground to comprehend what each is saying to the other. I explain in words – oral and written - any technical idea and provide the technical evidence, a code snippet as an example, to the BA since a ST chat is usually going on. And that necessarily is not the end of it and will clarify further if it’s clear or not. It has worked favorably on several occasions but if it did not help (or hurt instead) then I need to know. To be frank there is BA who knew nothing much about SQL and now he sort of understands it with bit of explanation. Since so much of our business logic is built in our SQLs showing the proof helps rest the case. In general I provide cut and paste as supporting item and not as a primary artifact. I can’t say anything further unless Greg provides more details and proves that it happens most of the time or all the time. I do not think so and do not want to nitpick on this any further.
Excessive/Unapproved Work from Home - Despite numerous conversations stating that he is required to give advance communciation and seek approval, BrownMan continues to work from home with no notice. During his 2007 year end review, he was told that all work from home, unless emergency, required prior notice and approval due to prior abuses of this privilege. BrownMan reached an agreement where he could work from home for days that he had pre-arranged dental appointments, but this also required advanced notice. Despite previous warnings, BrownMan continues to work from home unapproved, 7/28 – Child Sick, 7/15 –Sick. BrownMan is expected to be in the office unless previously communicated and approved by his manager.
The above section about WFH is taken up from his “warning” note and needed to be addressed. This did not appear in mid year comments but has made it’s appearance in the warning. I have already stated that work was so intense, there were constant deliverables and it’s impossible to take advantage of it even if you wanted to. I have dentist appointments once every 3 weeks and WFH on those days. Greg knows about this arrangement and has agreed to it. And for each of these I have notified in advance. Greg has to get back to me with proof if I did not. I wish I knew sickness in advance. Sometime if my family or I am sick and if I am not totally incapacitated I can manage to squeeze in time to work and so I can WFH. I do not like WFH unless I am needed at home or cannot commute to work but still there is work to do that if I don’t project timelines are affected. I have made this clear to Greg on more than one occasion in one on one meetings, in fact I have even stated that in one mail as follows and asked him to respond to a sick & WFH case – asking if he does not like I am OK to take SICK and not login to work at all if he wants it that way – but did not get any response.
Date: 04/17/2008 12:39 AM
Subject: Sick or WFH ?
Greg,
I am not doing too well with allergies causing me mild fever, runny nose etc., Considering I have quite a bit on my plate I am willing to work from home, not incapacitated, if that's OK with you or can take sick. I will charge my time accordingly. Please let me know. Either way I will join Rich Clew's call.
regards,
BrownMan
I can understand why he did not respond, he very well knows there is plenty to do and I am also needed around to answer questions from team members since the projects we were working on involved working closely with other teams across multiple locations and time zones. I also ensure that I work beyond 8 hrs on days I WFH. If not charge my time accordingly. In fact there’s so much to do that 8 hour days are not enough, especially in VARS group.
Summary
In the first half of 2008, BrownMan has made contributions to VaRs projects and resolved Level 3s. However, there have been a high number of issues his deliverables as highlighted above. Due to this, he does not meet the expectations of someone in his role and of his tenure due to the issues highlighted above. His errors have caused additional work for his manager, the Operate team and have jeopardized not only the deliverable but the production environment
His development opportunities, particularly Ownership and Accountability, are still present despite a 2007 Yearend review that stated he must improve on these qualities. For someone of BrownMan’s experience and tenure, he is expected to be able to work independently and complete projects end to end. However, BrownMan’s performance on his last two projects has been poor and he has not demonstrated that he can be counted on to work on projects and ensure they are completed end to end with high quality and no careless errors.
Additionally he must conduct thorough analysis and avoid mistakes that have occurred for the first half of 2008. He must also work with other team members and do thorough analysis and testing on his projects so that last minute issues are avoided.
BrownMan’s current performance for 2008 is unacceptable and must improve if he wishes to remain an employee at JP Morgan.
My Summary
Overall I have to conclude that Greg does not fully understand SDLC when it’s applicable or the shortcomings of it in a RAD environment like VARS when it’s not, does not plan accordingly and does not understand the impact of his priorities and decisions. He is unlike other Build Managers who are more technical and come from a background similar to environments they manage. CDS Idio VaR was a near perfect project from VARS side while SNPR/PCM/Market Data all had issues and fixes going on even in UAT. EMMI is going on as good or bad as it could be, even today’s release is postponed due to high level issues from EMMI, again. There is a tendency by him to generalize and extrapolate single and trivial incidents often to arrive at wrong conclusions. He is quick to make comments and suggestions in hindsight. Usually he has nebulous understanding of projects and if timelines and outcomes are not in his favor, mostly a result of his priorities and decisions, he gets frustrated and tries to find a scapegoat in others. What else could explain Greg’s comments?
One thing does and I am absolutely certain about it. It is tinted by his prejudices. That’s the Human element, pending with HR. Hence I will not be able to accept the warning and such since it’s based on factually incorrect conclusions. Frankly speaking I very much wish to remain and prosper as an employee at JP Morgan but definitely not working for him. The last paragraph from my letter addressed to HR echoes this sentiment and is as follows:
Dedication - BrownMan takes it upon himself to work long hours and weekends in order to meet his project deliverables. He has demonstrated a willingness to put in whatever time is necessary for the projects he is working on.
I have worked 70hrs for 9+ Consecutive weeks including weekends and including July 4th holiday - always logging in 3-4 hours after office hours from home up to midnight or past it. It was so intense Greg even mentioned that I should take a day off when all this is over. However I do not want it. I have used my own vacation days instead. Working after hours and weekends has become a habit that I continue to do it even now just to be pro-active on work items in advance.
Knowledge Sharing - BrownMan can be counted on to share his knowledge and experience with both the new Cognizant team as well as the Market Data team. Recently, BrownMan took it upon himself to help train the Houston Market Data team to run VaR impact analyses, This has greatly reduced the amount of dependency that the Market Data team has on the VaRs BAU team freeing up VaRs resources to work on other projects. Additionally, he has provided guidance to the new Cognizant team, helping to onboard new team members.
Not only did I have a presentation session to train the Market data team I sat through 2 of their projects helping them to do VAR impact analysis and test runs. Following is the Thank You note I received for my presentation.
Subject: Had a very useful presentation/knowledge sharing session
Greg
I just wanted to let you know that we had a very useful knowledge transfer session with BrownMan today. He covered several topics and provided detailed explanations to our questions.
I am confident this session will help us to analyze the impacts of market data and the nuances of testing better.
Thanks for his time.
ps - we may circle back with more questions, when we really start testing VARS.
Thanks
Vishy Raman
713-750-3576
I had helped the GUI team on Clearcase issues helping them move their code without losing history. With regards to helping Cognizant team apart from answering questions about VARS, I have helped them on few critical occasions (Sudipta’s lost code) to migrate code from Clearcase, my background in Version control and Clearcase administration was valued on these occasions. I have helped Greg on several occasions answering his ad-hoc questions regarding Calculators, Framework and sometimes on pre-project related aspects which has enabled him to answer questions from business or upstream. This was not assigned to any project in PAR and sometimes took significant time.
Opportunities for Improvement
Ownership and Accountability - BrownMan must demonstrate the ownership and accountability necessary to ensure his projects are successful end to end. The recent EMMI Phase 2 project was a good example where understanding the process end to end would have been very beneficial and could have reduced issues. For example, BrownMan did not catch an issue with processing multiple tenors that caused a code change late in development. This change was prevalent in multiple iterations of EMMi files and should have been noticed during one of the iterations of unit tests. In this case, BrownMan needed to ensure that all records of the input feeds were being processed correctly by the VaRs code. If he is unable to verify these types of tests, then he should reach out to other team members and resources for assistance.
I believe this is a red herring. On the ownership and accountability front I have done exactly what was instructed to me by my previous manager Anna Guarnieri considering the circumstances. It seems like Greg has changing expectations and says to cover up for his failures on the same aspect of ownership and accountability.
He gives the example of EMMI. EMMI project did not have a Business Analyst during most of the development phase. There was no formal analysis phase either. Our best BA at that time, Lee Sheard, had clearly told me that EMTS system was a “black box” to him. I had repeatedly drawn attention to this fact, on a recent occasion Greg countered it saying – “Well, I don’t have 3 Lees”. On upstream end the analysis phase was done by EMMI team late last year in which I participated on a question/answer basis providing information on how various fields in the feed are being used by VARS, the analysis was done from an upstream perspective to meet their goal of generating an EMMI feed. It was NEVER intended to be an analysis document for VARS. If there was a BA on our end who would have analyzed the same from VARS side the “multiple tenors” would have jumped right of the page and easily understood. There is another important reason why Greg did not care much about the need for BA - This project was based on the premise and promise that EMMI will replace the incoming EMTS feeds as is and all that was expected from VARS was that we do technical testing of the files to make sure they get loaded. Everything else would fall in place. But as the project progressed we uncovered about 50+ issues in a span of 3 months. Issues were related not only from VARS but Stress, SNPR and PCM as well. There was no way to compare the files and know all this in advance, simply because EMMI started portraying though it’s EMTS replacement it will not be really like EMTS, in EMMI trades were aggregated unlike EMTS and they did not want to migrate all the bugs that came with EMTS feed. Everyone involved including the management was aware of this. Most of the issues were captured at some of point of time, please see attachment 1 and attachment 2.
Considering the above it turned out that VARS was used as a testing ground to verify the feed quality both in terms of format and content. While some issues turned out to be enhancements most others were flaws. Once we realized the flawed trend our request for EMMI to unit test their feed before sending to VARS did not really have the intended effect as EMMI was focused on reconciling the data to Front desk and not benchmarking it against an EMTS feed. Once we started producing VARS results there was a project manager who was assigned as BA but it was too late too little, it was almost deadline. Initially she was also lacking EMTS knowledge that we had to rely on the business user to validate our unit test results. This was a case of doing UAT equivalent testing in SIT environments with no BA to validate the test results. About reaching out to others in the team – At the time I started working on EMTS except for one developer admitting that she does not know anything more than just testing the feed nobody else in the team knew anything about EMTS at all. Another person who had enhanced EMTS and no more in the BAU team also was very wary of making any changes to EMTS code since he was unsure of what the code was intended to be doing.
Greg did not share very important information during EMMI project. After few weeks after project begins I found out through some usage of words by the upstream manager in the meeting, words like “pilot”, that there are actually 2 phases to EMMI project. No sooner I heard this I approached Greg and told him just to confirm. Greg replied – “May be, I must have forgotten”. Greg either forgot or did not understand what pilot and full go live actually meant from EMMI side. I believe this was very critical information that affected our project planning. I had to scramble to get several code aspects in place to handle this, it was akin to processing a “new” feed in addition to existing feed and process them in parallel. We were having a weekly call every Wednesday for 5 months and there was an upstream project manager asking for him always. Though he had delegated this meeting to me from VARS side it was a case of extreme delegation which cost us, If not all he could have attended some to share/interact what he knew at various junctures. Definitely he would have been able to understand the gravity of the situation first hand with feed issues discussed above and not simply blame me for all the failures. Once he expressed his displeasure about EMMI manager – “Why should I manage HIS project” after some phone talk and one other time he told me after EMMI pilot sign off was received – “Screw EMMI” – 2 clear instances that proved he did not like EMMI.
Additionally, he must be aware of changes in his environment that could impact his deliverables and be sure to coordinate with other teams that are using the MRT Production and UAT environments. In the both the CDS Idio-VaR and EMMi phase 2 projects, BrownMan missed multiple issues that should have been caught prior to UAT including:
- VaRs changes were not merged with MRI Backfeed ValSrv code changes for CDS Idio VaR.
- ValSrv changes were not correctly labeled and thus not picked up in the first CDS Idio-VaR test runs
- UAT forms and testing procedures were not coordinated with SNPR and PCM teams for CDS Idio-VaR
- Changes to Market Data jil jobs dependencies were made after BrownMan’s clearcase branch was created. BrownMan did not check for those dependencies and thus those changes were not incorporated in the original EMMi release. This caused a production issue.
Simply put, BrownMan must ensure that his projects run smoothly and do not encounter the last minute changes that have occurred on both the EMMi and Idio-VaR projects. While he has been working on 2 projects with tight timelines, he must ensure that his work is of top quality and ask for help if needed.
Since priorities keep shifting Greg has more background and information on when projects are going live. He did not share one of them sooner. On the day of UAT start for CDS Idio VAR project the ValSrv was packaged well and all set to be tested. But then he drops the line – “MRI Backfeed changes need to be part of your ValSrv”, I had no inkling of this going to come. The previous Sunday night there was a mail from one MRI Backfeed team member says “I think this has no conflict with our ValSrv” but nothing more. It’s common in VARS to run separate ValSrv before they get merged. MRI Backfeed changes had already been tested in UAT and if anyone they or Greg had better idea of when those changes are going in with what, in this case if their changes are going in with CDS Idio Var or not. Anyway as soon as he informs I got the configuration spec from others, removed my labels, merged MRI Backfeed code and built the binary. Even this did not compile on UAT end as there was another ValSrv change (RMBS) that even Greg was not aware of that needed to be merged – So I had to merge two other ValSrv changes to mine in the last minute while UAT was waiting on us.
Because of this in the rush I did not put the label back on 2 files which originally had it. This is a minor issue usually caught by Configuration management person and happens all the time but on this instance he also failed to mention it. He has to lookup the UAT form to gather all the code with a specific label and if he does not find any he responds back. That did not happen. This mistake cost us 2 days in UAT which was not entirely wasted since we discovered two other non VAR issues in that run. Considering that subsequent UAT run went on for 3 weeks, with PCM / MktData /SNPR code fixes, this matter seems highly exaggerated. 2 more weeks went by since there was a SNPR bug in legacy code before the project went live. I did not have a single code issue in UAT. The root cause was that Greg did not share the information he had which would have prevented these trivial happenings (these account for first 2 issues listed above).
About UAT forms and testing coordination it’s an additional responsibility I have taken up, but it’s not easy without cooperation from SNPR, Stress, PCM and Market data teams. For all the projects I have done so far I am the one who has collated all information that makes up most of the UAT form. I always ST and make phone calls to update/inform but haven’t received timely cooperation from others always. Other teams have their own priorities as spelled by their respective management and the message does not get across. In case of CDS Idio VAR project SNPR team was still making code changes when I was ready with the UAT form. Even on the day of UAT the form was not ready. They did not have any idea what the project is about either let alone how to test it. I was explaining them in detail on the day of UAT. The onus cannot come from VARS always when other teams have respective deliverables and equal responsibility and accountability. Whatever the reasons coordination despite being done does not elicit the desired response. I have ST evidence to prove this. Management push is required and I have used Greg whenever required. And if Greg thinks enough is not being done or achieved then he needs to step in.
About the production issue, I agree, but need to elaborate on this odd one. This was my first Production issue in 2 years with JPMC. And this happened because production support, not AD person, had introduced a dependency in a jil job, this happens very rarely, these dependencies are not identified by compilation processes. It was not a C++/script code issue. When the issue was raised to me I resolved it within half an hour after diligently working with Market data team and finding out the root cause. Proactively I informed larger development team what other jobs might be impacted because of this change introduced by production support.
All the issues highlighted by him are technically trivial, I have already stated the reasons for “last minute changes” and how they could have been avoided. Working on 2 projects was tight but never the reason for issues stated above. In fact Greg at one point gave me a choice to lighten my workload but I opted to continue to work on both projects. I had dedicated my time so much to both that I did not want to lose any credit for all the hard work that I had already put. And I really wanted to succeed.
Attention to Detail - BrownMan needs to spend time to do thorough analysis while working on a project. He missed an important piece of analysis in the CDS Idio-VaR project in that he did not notice that the VaRs conversion code was not retrieving the SPN name for certain source systems in the Instrument field. This was caught late in the project and a quick fix, that will need to be cleaned up in production, was implemented in order to meet the current project deadlines.
These statements are distorted. About the item he mentions about the CDS Idio-VaR project it was clearly a sudden expansion of project scope. Initially the BA had stated that – “Instr field was already expected to be in the XP with the SPN/UCN information”. Based on that available precondition we had several rounds of to and fro communication to arrive at a conclusion in terms of what needed to be done to get the project done. And I had given my estimate based on that premise. One day in the morning BA said it would not work for two source systems out of many. Immediately I started researching and arrived at a technically accurate solution within half a day. With this it was possible to continue work without affecting timelines. I conveyed my finding to Greg the same afternoon. Taking the classical approach would have cost us 2 to 3 weeks of additional effort in development and testing without any additional business value. He did not complain then but said we will have to clean up later. And I agreed and proceeded. I am not sure why this is misrepresented this way.
In general talking about attention to detail I can give numerous examples to support. Apart from 3-4 projects I have done so far I have done about 12 to 15 L3s. Some of the L3s I have researched in detail and have resulted in their scope being identified as projects because of the level of detail I put into research and interaction I had with business and upstream. In the course of CDS Idio VAR project I went beyond VARS scope to identify what needs to be changed for SNPR/Stress and conveyed to that team. During UAT phase when a defect was reported from UAT I fixed 3 defects on SNPR code proactively when the developer from that team was not around.
More attention to detail could have avoided the EMMi multiple tenor issue as described above as this was documented in the EMMi requirements that he helped to document.
I have already explained this above. It was EMMI specific doc and was stated in obscure comments section. It’s too important that it deserved an internal analysis document from VARS side created by a VARS BA considering how VARS was processing tenor in legacy code.
Communication - BrownMan has had issues with his communication this year. For example, he will often send cut and pastes of code to non-technical people when describing an issue. This has led to confusion and does not reflect well on BrownMan or his team.
Greg has not provided detail about this. So I have to guess from where this is coming from. I believe in cooperation and team work to get things done. As an IT person I was hired as a Software Developer primarily and not as a finance person. Finance is a secondary skill that I am constantly learning and improving upon. The situation is reversed for a BA. And when the two of us talk we try to reach a middle ground to comprehend what each is saying to the other. I explain in words – oral and written - any technical idea and provide the technical evidence, a code snippet as an example, to the BA since a ST chat is usually going on. And that necessarily is not the end of it and will clarify further if it’s clear or not. It has worked favorably on several occasions but if it did not help (or hurt instead) then I need to know. To be frank there is BA who knew nothing much about SQL and now he sort of understands it with bit of explanation. Since so much of our business logic is built in our SQLs showing the proof helps rest the case. In general I provide cut and paste as supporting item and not as a primary artifact. I can’t say anything further unless Greg provides more details and proves that it happens most of the time or all the time. I do not think so and do not want to nitpick on this any further.
Excessive/Unapproved Work from Home - Despite numerous conversations stating that he is required to give advance communciation and seek approval, BrownMan continues to work from home with no notice. During his 2007 year end review, he was told that all work from home, unless emergency, required prior notice and approval due to prior abuses of this privilege. BrownMan reached an agreement where he could work from home for days that he had pre-arranged dental appointments, but this also required advanced notice. Despite previous warnings, BrownMan continues to work from home unapproved, 7/28 – Child Sick, 7/15 –Sick. BrownMan is expected to be in the office unless previously communicated and approved by his manager.
The above section about WFH is taken up from his “warning” note and needed to be addressed. This did not appear in mid year comments but has made it’s appearance in the warning. I have already stated that work was so intense, there were constant deliverables and it’s impossible to take advantage of it even if you wanted to. I have dentist appointments once every 3 weeks and WFH on those days. Greg knows about this arrangement and has agreed to it. And for each of these I have notified in advance. Greg has to get back to me with proof if I did not. I wish I knew sickness in advance. Sometime if my family or I am sick and if I am not totally incapacitated I can manage to squeeze in time to work and so I can WFH. I do not like WFH unless I am needed at home or cannot commute to work but still there is work to do that if I don’t project timelines are affected. I have made this clear to Greg on more than one occasion in one on one meetings, in fact I have even stated that in one mail as follows and asked him to respond to a sick & WFH case – asking if he does not like I am OK to take SICK and not login to work at all if he wants it that way – but did not get any response.
Date: 04/17/2008 12:39 AM
Subject: Sick or WFH ?
Greg,
I am not doing too well with allergies causing me mild fever, runny nose etc., Considering I have quite a bit on my plate I am willing to work from home, not incapacitated, if that's OK with you or can take sick. I will charge my time accordingly. Please let me know. Either way I will join Rich Clew's call.
regards,
BrownMan
I can understand why he did not respond, he very well knows there is plenty to do and I am also needed around to answer questions from team members since the projects we were working on involved working closely with other teams across multiple locations and time zones. I also ensure that I work beyond 8 hrs on days I WFH. If not charge my time accordingly. In fact there’s so much to do that 8 hour days are not enough, especially in VARS group.
Summary
In the first half of 2008, BrownMan has made contributions to VaRs projects and resolved Level 3s. However, there have been a high number of issues his deliverables as highlighted above. Due to this, he does not meet the expectations of someone in his role and of his tenure due to the issues highlighted above. His errors have caused additional work for his manager, the Operate team and have jeopardized not only the deliverable but the production environment
His development opportunities, particularly Ownership and Accountability, are still present despite a 2007 Yearend review that stated he must improve on these qualities. For someone of BrownMan’s experience and tenure, he is expected to be able to work independently and complete projects end to end. However, BrownMan’s performance on his last two projects has been poor and he has not demonstrated that he can be counted on to work on projects and ensure they are completed end to end with high quality and no careless errors.
Additionally he must conduct thorough analysis and avoid mistakes that have occurred for the first half of 2008. He must also work with other team members and do thorough analysis and testing on his projects so that last minute issues are avoided.
BrownMan’s current performance for 2008 is unacceptable and must improve if he wishes to remain an employee at JP Morgan.
My Summary
Overall I have to conclude that Greg does not fully understand SDLC when it’s applicable or the shortcomings of it in a RAD environment like VARS when it’s not, does not plan accordingly and does not understand the impact of his priorities and decisions. He is unlike other Build Managers who are more technical and come from a background similar to environments they manage. CDS Idio VaR was a near perfect project from VARS side while SNPR/PCM/Market Data all had issues and fixes going on even in UAT. EMMI is going on as good or bad as it could be, even today’s release is postponed due to high level issues from EMMI, again. There is a tendency by him to generalize and extrapolate single and trivial incidents often to arrive at wrong conclusions. He is quick to make comments and suggestions in hindsight. Usually he has nebulous understanding of projects and if timelines and outcomes are not in his favor, mostly a result of his priorities and decisions, he gets frustrated and tries to find a scapegoat in others. What else could explain Greg’s comments?
One thing does and I am absolutely certain about it. It is tinted by his prejudices. That’s the Human element, pending with HR. Hence I will not be able to accept the warning and such since it’s based on factually incorrect conclusions. Frankly speaking I very much wish to remain and prosper as an employee at JP Morgan but definitely not working for him. The last paragraph from my letter addressed to HR echoes this sentiment and is as follows:
“Unfortunately my experience with Greg has been hopeless. His behavior does not
reflect the core values of our firm, definitely unbecoming of a VP. I sincerely
hoped he would improve for the better over time but it has not happened. Since
late last year he is also my direct manager. Despite my best efforts at my job
duties I believe it has cast a shadow and influenced his opinions about my
performance. Recently in mid-year review comments he has distorted, exaggerated
and obfuscated facts. Despite setting me up for failure in many ways I have done
extremely well considering the adverse circumstances, In fact I was expecting
“Exceeds Expectations” rating. I have not missed a single delivery of work item
so far. I am writing a separate rebuttal about this to my management and will
copy you when I am done. In short, I will not be able to continue to work and
perform my best in this environment any further. I am looking forward to your
help and immediate corrective action in this regard. If you have any questions
or need further clarifications please contact me at the earliest. Thank
you.”
