Instances when you adopted new innovative ideas from your team or elsewhere to improve and simplify your product/ Process. How do you quantify the benefits? What was the learning?
Below is what i actually submitted to Amazon and after that i was called for a F2F interview with them.
One of the most satisfying moments in my career was while I was at XXXX.
I led two mission critical and high visibility products in the YYYYY department. To give you some context the YYY product has over 450 Hospitals as a client base and run at some of the most important hospitals in the US.
When I came into the organization, XXXX was in the end stages of porting the YYYY application to a newer technology. At the same time through the existing team we had to maintain and support the older line on an older technology. Towards the end of 2014 as the product was GA we had issues crop up from our Beta customers and we were caught up in addressing issues as soon as they came. Given the limited resources and the need to support two lines of the product it was apparent that we will soon be hitting a crunch on time and people resources.
The first thing that I set about to optimize were the following
1) Sync-up meetings (Bangalore Team -- US Team)
On an average the team were spending 2 hours updating their status of tasks one at beginning of the week and the other at the end of the week. So cumulatively given a team size of 15 that is a cumulative 30 hours.
Why did I feel this was important?
a. Breakdown in stakeholder communication
b. Lack of trust.
c. Effective hours spent in office
d. Colleagues get frustrated.
Root cause & Fix
Team tended to take on more tasks without understanding the depth of the problem. Also since the new product line was developed by consultants and handed over to the DEV team we were also stuck with issues coming out of regression testing. This led us to over commit based on our capacity and led to slip up on tasks.
I approached this issue by including my Director in Bangalore with a plan of approach and gaining consensus so as to
○ Limit number of participants to Engineering Manager, Lead, PM, QA lead and reduce the duration and frequency
○ Setup a separate meeting that included me and counterparts in the US middle of the week to sync up on team performance
○ I worked with the team to improve the communication to key stakeholders by first breaking down the task the least possible work item and providing an better estimate.
○ Spoke to my counterparts and laid out a plan of improvement over a Q-O-Q basis and then was successful to bring this down to a half hour meeting in a week as they saw improvement in the team performance.
2) Service Package Quality (SP)
We deliver code break fixes on a monthly basis to our customers, package quality is a metric used at XXXX which roughly calculates the number of client downloads of the SP versus the number of tickets raised against that down through support.
This was one of the biggest challenge that I faced, how do I improve my teams code quality and have customer base that is raving about our quality. At the beginning of my journey with XXXX the package quality roughly stood as follows, Q3, 2013 was the timeline when I joined XXXX , this was the challenge I was faced with a worse package quality that has visibilty of all the VP at XXXXX. Towards the end of my tenure I was able to move the bar higher for the team through these slew of corrections
Root Cause & Fix
• QA at XXXX is a separate organization all together and I realized that though there were one or two QA persons involved in testing, we cant improve our quality if QA leadership isn't behind us. We had to find a way to collaborate better and work on improving quality as a team.
• Co-ordination : QA and Dev were not aligned on the nature of change, for a proposed change in code, QA wasn’t given time to align their test cases or time to write new test cases as all the estimates were given by the architect who didn’t consult with QA lead on what their estimates would be.
• No formal design review meetings at engineering level. Failure to identify true impact of change.
• No formal code review mechanism, though the team already had a process of using Crucible Review they were not implementing it.
• Right size the delivery items, justify with data on how many items we can fix realistically per SP.
• QA team missing key testing areas
• Whitebox testing issues from developers
• Lead Architect and developers trust issues and breakdown in environment
• No Gated check-in concept so as to catch the failure earlier
• No automated unit testing frameworks used.
• Setup a collaborative environment working with the QA Manager and worked together with him to get QA resources behind our release, to ensure a stringent release process we started bug bash sessions, unscripted testing.
• Lead from the front by driving all the meetings and code reviews. We introduced a concept that architect needs to review code along with two other engineers to be allowed to check-in and any build failures to be caught early.
• Setup meeting and training with the team on identifying issues in code and how to analyze impact of change areas.
• Worked with the team and their feedback on improving team environment by ensuring that any code break is not a persons fault but a fault in process that needs to be improved upon
• Architect took up the challenge to setup a Jenkins box to allow us to build first on our local environment before code is checked-in to ensure we do it right the first time.
• 20 to 30% increase in Service Package Quality numbers quarter on quarter compared to where we started in Q3 2013
• 100% critical enhancement and bug-fix delivery to clients for Obligations (customer funded fixes)
• Improved customer feedback and reduction in number of support tickets open