Amazon Technical Program Manager Interview: Ownership

tell me about a time where you were dissatisfied with the status quo or you did something of your own responsibility [Music] hey everyone i'm here today with arvin we're going to be doing a mock tpm interview from amazon where we'll be asking a behavioral interview question about ownership one of the amazon's leadership principles in today's interview question i'll be asking arvind tell me about a time where you challenged the status quo where you took responsibility for a decision on your own before i jump into it arvin could you introduce yourself briefly for folks watching sure

thank you stephen thanks for having me today i'm a senior tv i'm at amazon i work in the aws business of amazon in my pre-life i used to work as a senior engineer at lexisnexis which is uh more into the information research on the legal analytics side of the world i also went back to school at fuqua so go blue devils without a doubt uh spent a lot of time doing program management project management and also like uh spent a lot of time being an engineer as well that's about me in a nutshell and if

you have any specifics please feel free to awesome um well super excited to have you arvin in today's interview we're going to be focusing on the leadership principle of ownership um we're specifically going to be talking about the following question tell me about a time where you were dissatisfied with the status quo or you did something of your own responsibility sure thank you can i take a few seconds to think through it and probably come back to you on it absolutely go for it thanks steven thanks for that uh i would like to take us

back to like few years ago 2017 early 2017 when i joined this new team after being part of a different team wherein i was not only a technical lead but also it's from master uh wherein we try to redefine the practice management side of things but when i moved to this new team in 2017 i had an opportunity to work with amazing engineering minds who actually have been interpreting this process are probably like working on this uh amazing crm platform for a really long time like almost 15 years one thing that actually quickly found out

was their release management and deployment processes were not up to the mark what i mean by that is uh if you have a new new new code that actually was ready for deployment or probably like when we were trying to take care of a customer request the whole process used to take almost a good number of six to eight weeks and i quickly figured that this actually could be refined based on my previous experiences however it's not easy to navigate when you join a new team right so i took some time for a period of

like next six to 12 weeks i worked with the people who were involved in the process i was trying to be the listener on the call so probably like just like sit right around the people when they were doing it i try to identify write down the pain points that actually i have noticed from my firm beliefs not something that actually i would say they actually felt the same way as well so i took it took a step back i figured that this needed actually a better plan something actually that i could probably like streamline

and put in a wiki or probably a document saying hey here's how we should be looking at a three or uh two years down the lane so when i started actually putting the pieces of the puzzle together i quickly understood that there is potentially a very good chance that we actually could have this deployment streamlined in a way that instead of taking that six weeks of deployment we could have a process that literally could be simplified and we could have a deployment done within the same day that's pretty much the situation and the actions that

i took and literally this is where actually it moves from strategy to tactics right i had to work with the engineers as well as the db people and pretty much everybody else involved involved in the process i need to get the buy-in from people i need to get the resources that are required so that's something actually wherein i took a step back i tried to come up with a plan i worked with my architect who was super supportive of this idea because he and i actually in our previous lives as in my previous project we

actually put this process together in this release mechanism together where and things were so solid so having worked with that architect for a while and putting the plan together we literally came up with a simple step-by-step process so that we can get to the farther end like within the next six to 12 months we are able to start putting the action plan together and we had we started automating bunch of these processors and enabling enabling these people with the right skill sets as well as the right tools and everything i would like to say probably

like within nine months timeline we had our first deployment which was totally automatic pretty much like when we we had a very little amount of uh human and involvement involved there as in like all we had to do was take care of one particular process that we had to kick off which we did not do and we actually started putting the pieces together and when we talk about uh 2019 that is where actually i could proudly say that by 2019 we were able to start uh deploying pretty much on like every time there is a

code checking that happens we actually started seeing flow happen uh seamlessly and in simple words if i were to quantify this impact uh the thing that used to take six weeks actually can be done in one day right now uh we actually kind of borrowed this model from facebook we are doing things wherein uh we learned that they actually deployed more than twice or at least like seven times a day if i'm not wrong so we try to emulate something similar so that's what we ended up doing from a customer uh looking back at like

how customer would be impacted or probably benefit from this it's more of like how many releases can a customer have within a given year uh this very team in 2017 or prior to 2017 they used to have maybe like three or four uh deployments every year from that we actually moved to a state wherein we had 24 deployments in 2019 it probably speaks volumes about it wow i um well you can definitely hear the impact there of of your changes irvin i'm curious what was the reason that there weren't deployments before or um what what

sort of like challenges did you have to face when you were changing the status quo for that organization sure uh i think a wise man once told me that there are three things that actually impact any project which is like people the product itself and probably uh the product itself right like if at all you want to make any change the product itself actually has to be uh we should be able to do it like one of the elements that we had there was uh the on-premise side of things we could never ever actually move

that to a streamlined deployment process but there was this cloud side of things where we could actually start putting these pieces together however it was not easy for us when we started the journey uh which goes back to the second p which is people these are amazing people without any doubt i am not going to disagree on any given day but the reality is they have chosen to stay one way or they have chosen to work one way and it actually challenges their mental model and it's not easy for anybody like trust me even when

i am set in my mental model i probably not operate the different way it takes time for me when i have to challenge myself and try to make sure that i correct my understanding and go back to it so working with people and trying to understand their intentions behind it and their intentions behind doing it the manual way because they deemed actually doing it manually would actually allow the process of verification kicking and with the process of verification they always felt that level of confidence was close to like that 95 but which could easily be

even uh uh be supported by automatic deployments as well so we had to put a process in place we had to make sure that the product also scales along with us and also get the buy-in from the rights of people one good thing which actually i forgot to mention uh through this process is there was changing leadership the change in leadership also helped us uh back in the days when we had a leader who was supportive but he was not willing to actually make these subtle changes that actually could change the culture within the team

the change in leadership also truly helped us got it got it um and um you know we may not discuss this as an actual interview but this interview is asking about ownership a lot can you tell me a little bit more about how you took on ownership or maybe ways that you struggled with ownership in this particular example sure i could certainly do that so let me go back to 2017. uh i actually just like joined the stream i was trying to make my mark in the first six months i could have probably just i

could have just rammed up and probably like picked one of their items on uh sprint backlog right what i chose to rather do was not only do what i was supposed to do as an engineer on the team i actually chose to even take a step back and sit down with this uh with this other engineers who are involved in this process who are doing the manual deployments i took time out of my play like out of my personal time i sat down with them i tried to understand what they were doing and the there

are these two amazing engineers that i we used to work with uh these people actually shepherded the process pretty much for a while they had a really good run book but the reality is that runbook was as good as like when they can run it because every time there was a need for refinement we had to work with them what i did was i took that ownership of like this runbook is great but can we automate it in a way that actually we don't need a runebook so it took that ownership of like translating that

run book into pretty much a scripted way of getting things done it's pretty much like push-up button and everything happens magically or automatically however you want to see it awesome um well that we're getting close to the end of this uh particular question but is there anything else that you would have done differently or something you might have changed when you look back on this experience that's a really good one um one thing that i think i could have done slightly better was actually trying to get in the buy-in from the engineers or probably like

even from the leadership sooner than later uh it goes back to what actually john carter talks about right in his leading change book uh it's more of like uh providing that sense of urgency sooner than later uh that's something that i lacked i'll be honest 2017 i was not as smart as i am today i'm hoping that i'm smart as of today but the reality is uh when i read that book it actually reminded me the fact that when you want to change your environment or probably like pretty much something which happens to be a

cultural change within your team you need you need to get the buy-in and also you need to get your buy-in in a particular way that uh you not only are sending them the right signals but also they give them the sense of urgency of why this is important and it was important for us to actually make that move because once we talk about the next example you will actually figure out uh how i could uh type the loose ends uh that example's pretty much uh it just like puts the pieces of the puzzle together for

you and when we get to that we'll certainly uh understand it but the reality is within like two to three years we translated ourselves from a a engineering group which was actually shipping four times every year to pretty much like yes i have this feature already you need to just like uh switch this feature on and once you switch the feature on customers can see it like pretty much right away if you want them to so it's a sense of urgency i actually probably liked that skill i learned it over a period of time and

i'm still hoping that actually i'll be able to do it at amazon as well and thank you for asking that thank you totally um well arvin we're wrapping up this particular interview is there anything else you want to say about the example or situation uh before we kind of jump to talk about feedback and how we felt like the interview went yeah good awesome um well thanks for doing it you can take off the interview we had you did a great job it was really really awesome i have a lot of notes about what i

thought were really effective about it but before i say what i thought was really effective did you have anything you wanted to share more of like a self-reflection about how the interview was or any any thoughts on it sure i could certainly do that usually i tend to use a scale so that helps me improve my my own practice or like when i practice i used to do this i used to ask anybody to rate me on a scale of one to five if you allow me to rate myself on a one to five year

i'd probably give myself a two and a half wow uh that's much slower than i thought but tell me more what did you think went well and what do you think you would improve i think what it did very well is actually talking about the situation elaborating it and probably like enumerating some of the the actions that we took or i took as a individual what i lacked in this particular example was i could have done slightly better when i tried to put the impact that impact side of things i i don't think actually i

did a really good job but i could be wrong and i'm i'm usually known for being very stunned on myself totally um well so here's what i thought you did really well and what i thought you would improve so first of all i thought the example that you picked was very palpably clear and very relevant to the ownership leadership principle which is what we're targeting or talking about today you know you moved a process that was a six week process to a one day process and you changed a three to four deployment per year to

a 24 deployment per year situation which is very tangible and quantifiable which is really awesome about this particular one not all answers have to be so quantifiable but it helped and it built up the impact that i think you had on the team i also thought you did a great job of discussing the elements that you needed to discuss without getting so technical that it might be irrelevant to me so um oftentimes people fall into the trap of just going on and on about a technical detail or something like that um you sort of stayed

a little higher level which was nice and you know i certainly could have asked a little bit more like oh what deployment etc etc but it got me the information that i needed to interview you effectively which i thought was really awesome um i also i thought that there was um a really thoughtful discussion and really great responses to the follow-up questions that i asked um and so you know i asked some pretty hard follow-up questions or maybe ones that you might not have expected or kind of took it in different directions like what would

you do differently or things like that and i thought you handled them with grace you you always were like that's a great question here's how i would change it um so i thought that was all really effective i think like in terms of feedback i think um there was probably some opportunity to interact with me a little bit more or ask like you know do i know this thing or you know this is kind of the situation or even um you did this a little bit toward the end you mentioned like two engineers you worked

with that were really great even bringing in a little more of your emotional perspective or you know it was really hard or it was really awesome or you know etc etc can kind of humanize you and humanize the the process because at the end of the day these are behavioral interview questions and so the interviewer's not only looking for the content of what you say but also just you know your pleasantness as a person to work with and maybe just your emotional candidness throughout that interview answer but anyways any other thoughts reactions to what i

just shared or any other tips that you want to share to folks watching i think i missed on one thing when you asked me earlier if there is anything that i would like to add um that actually goes back to being able to provide a nugget uh what i mean by a nugget is i heard this somewhere and probably written a book as well when you talk about a behavioral situation it's recommended actually provide a 15 second nugget saying hey here is what i want to talk to you about is this of any importance to

you or any interest to you if you actually ask that to the interviewer you kind of captivate them within that 15 to 20 seconds and that also gives them a very a simple understanding of probably a very simple way of understanding like what the problem is about or what the situation is about so that actually they can start writing starting writing their notes and probably like even start picking what they want to ask for that's something that i have utilized actually through my process and even during my amazon interview i forgot to mention that i'm

extremely sorry for no i love that that's a great point um yeah is there anything else you want to share with folks watching before we wrap up uh the this particular interview and thanks for the feedback yes i agree with you mostly pretty much with what you said i could have tried to humanize the uh humanize my experiences there i'm sorry i did it no i i yeah totally overall arvin i think this is an amazing interview by the way and i think you did an excellent job of articulating your points and um i think

there's a lot of self-awareness and um that you have which also adds to kind of the um the effectiveness of the interview that you have um so i thought this was an amazing example um and you know again i wanted to thank you arvin for taking the time to interview with us and for folks watching if you have any questions or comments feel free to let us know in the comments below and arvin and i will both help out to answer any questions