So I am a technical program manager, and I work at Amazon my whole career only. But at Amazon, um, I started working for Amazon in customer service, Uh, just taking phone calls. Then I got promoted. Teoh be supervisor of customer service agents. Eventually transitions like a program manager, sort of ah, role for managing operational excellence for the developer. Teams that supported customer service. Um, then ambled onto a supporting support engineering role and eventually became a TPM, which is what I wanted to be. Um I think the biggest jumps in my career went from when I was a program manager to a support engineer and from a support engineer to a technical program manager. Um, I took two CS classes about basically for python uh, one a 1 to 102 uh, which basically gave me the ability to do scripting while I was a program manager. Um, I was managing how many contacts with the developers get for bugs and issues from customer service, which was in the thousands, which in turn created a lot of costs for the teams because most of the times that problems were self like resolvable. So, after working there. He got really interested in i e started TCs classes. And then I learned how to script. Um, And through that job, I got connections, uh, with the managers for development teams that wanted me to be their support engineer to manage their operational excellence, specifically not for the entirety of the 100 teens. Um, and that's how I got to be a support engineer. I passed. Ah, the technical bar in the interview. Um, it was a very rewarding job and taught me a lot about, um, software suffer development, project management program management. And then, um, that kind of was a stepping stone towards my final goal, which has become a technical program manager, um, where you're less involved with one teen or one development team. And you're more like coordinating across multiple development team to develop a product or to meet a programme or project. Um, and so you get a lot more exposure, and it's a lot more complex because you have to deal with many moving pieces. But there's also, like a product business aspect to it. Um, I got to be that because I got opportunities when I was support engineer to manage programs and projects over less complex. But I did enough of it that I got the hang of it, Um, and eventually I decided to make the jump in there the same way I found the manager who was willing to support my transition and roll. Um, I went through the full round of interviews, met the technical bar again, and then I was able to transition successfully, and that's what I've been doing ever since.

so responsibility wise, I am the sole owner for the success of a program or a project. Um, so that means that I am single point of contact for the self of the building managers for the engineers, for management as well, um, and for business. And so my job is to bridge. Uh, what? Somebody comes to me and says I want this product to translate that. Teoh, How does that look? Like from the engineering perspective, it makes sure that the two pieces are never out of sync and that we deliver based on the timelines and the commitments that we made. And so overall, I end up being the owner, even don't know, really working on the ground on what's being delivered and making sure that everything goes according to plan. It is. It doesn't. I need to have ah, back up. Which is there is medication, basically So owner of the product owner of, like, absolute risk mitigation, Um, whenever I'm working on a project or I own a project in terms of work hours, um, I am a salary employee. And so that means that I, the really bill are not I guess me as a person don't bill Amazon by the hour. The expectation is that we would work 40 hours a week, sometimes more and sometimes less. And that's one of the caveats of being a salaried employee. Um, you have the liberals and whatever it is that you need to do to meet that deliver verbal with the time Ling. You do it, um, and sometimes handle working 30 hours a week since isis 60. Sometimes it's 40 and so it's variable. But I would say between 40 and 50 hours a week is my average, um, work travel. Working from home? Um, I live 10 blocks from work, and so I usually walk or I used to walk. For the past four months, I've been working from home. We've been extremely flexible with the working from a policy. If you can do your work from home, you are very encouraged to stay home, even though it's three offices have, like a very high standard of like sanitation because of the coca situation. Um, for me personally, there's no using going to an office If I can't see people face to face or if they're not willing to come into a meeting because there's this aspect of, like, um, interpersonal relationships. When you're managing projects, that's important. But if not, if nobody else is there, I don't need like that to modern or three monitor displays in the sea. And so I end up just staying at home and I make my workstation very comfortable. Um, and that's where probably be for the near future.

one of the big challenges that I have encountered throw my career but that I also find, really where Warden is dealing with ambiguity and dealing. Ambiguity is a really life. Not many problems are super well defined when you get into software. Um, there many ways of doing things and their many ways of, like, tackling and free me a problem, which means that there is generally a lot of ambiguity around, how you're going to do something, and that's been ever present since I started as a customer service agent. Until now, it's going a lot more complex, and as time goes by, you deal with a lot more of it. And that's kind of like a reward. It skill, especially as you're going to like leadership roles and more senior rules, that somebody will be able to give you something that doesn't have any edges or corners, and you're gonna figure it out and then figure out what shape it actually has, and that's your job. You need to be able to be independent and be able to resolve that problem. Um, the other thing is challenges, complex and multi year projects. It's really easy if I tell you pick up that box and put it there have well defined, like command the problem. But if I tell you I want you to build me a system that's going to take the box or dislocation and then go take it to the other location that has many things right? Like, Do I have a robot that I have a person? What are the locations? Um, and you have a timeline, and so these get a lot more complex and they're less easy to visualize or less easy to comprehend. At the get go, you have a general idea. But this could go for years. And so multiyear complex problems can be challenging. They could be really rewarding, especially if you know how to break them. And that's something that you learn what time. But nevertheless, it drives a lot of growth, but it can still be a challenge