 Welcome to Having Coffee with Smoke. Together with Gary, we'll be discussing the role of manager. So thank you for joining us Gary. It's a pleasure to have you here. Pleasure to be here. So Gary is manager here in Amazon. He was my manager for a short period of time. And right now you're managing other managers as well. Indeed, yes. So I'm managing three engineering teams. But two of those engineering teams I've managed for other managers. So a lot of people to manage. Yeah, it comes easier. It's like when you've got other managers there that you know you can rely upon and depend upon to do what you would have been doing before. You're in the role for how long? I can give you a bit of a history there. If I give you my career history, I think you've heard me say before, I'm kind of an accidental manager. My passion started with software engineering. I did an unusual career path that I started out in telecoms fairly long time ago, 30 years ago, as an apprenticeship. Which is interesting because Amazon started apprenticeships again now. So I started out in telecoms and I actually did climbing poles, dig in holes. Actual engineering. I did cool centres and how to manage ticketing systems. And at the time, software wasn't as prolific as it is now. There was very much data centre teams and mainframes and big systems. But things like Visual Basic were coming into the frame. And it was probably my first introduction to agile programme. I was in business teams, but I was automating things. So processes that were very labour intensive. I got involved in writing programmes to automate them. So you were software engineer in something like full blow? Yeah. So for 15 years I was full on passionate about software engineering. And then ended up in this interesting situation where I became involved in more and more meetings. So I would be the person that would go to meetings and come out and talk to people about what our next thing we should be working on. So it became like a team leaves. Yeah. Them and us. Exactly. Who was the volunteer to go into the meetings? And it was like, we don't want to go. Gary, can you go to that meeting? Or Gary, we need to plan something. And because I had the experience of getting involved in the planning side of things. So there's two aspects to this, a willingness to communicate and engage with people. And that helped come in from a background of being in business teams. Of knowing how to speak with different people from different backgrounds and interpret engineering speak, coding, in-runs through business and vice versa. So I kind of hope that this will help people that are thinking about transitioning from SDE role, software developer programmer into more managerial circles. Is this a good idea? What is the most gratifying about this role right now? And what are the common misconceptions that you had before going into managerial role? And what is your view on the thing right now? Probably an interesting thing because I never had a perception of ever being a manager. I just happened to go down that path. But those two aspects of this, like you're talking back in year 2000, between sort of 1998 through to 2005, career paths were very much oriented. If you wanted to progress through an organization, you weren't management. There was very little, in Amazon we have this fantastic thing of, and you see this a lot in other organizations, of engineers can have a career path that is pure tech. You can make very senior levels of being Amazon and be a pure technologist. That wasn't the case that time. So in my days, you'd maybe get to a technical architect, but from a technical architect is like a senior engineer. And then you still wouldn't be managing people and you'd have broad impact. But then after that, it's management. You're not becoming a people manager. Now, one of the other things that maybe led me to, so that's sort of a career decision nowadays of, do I want to manage people? Or do I want to continue being a pure technologist? Now I look back in hindsight, what I'm really passionate about now, where I look at the values of organizations is, so if you look at Amazon's leadership principles, engineers are about insist on high standards, dive the very engineering practices, and a manager's role is about hire and develop the best. So the great aspects of being a manager in an organization like Amazon, and really, if you want to go into a managing role, there is a degree of having control of strategy and things like that, but it's seeing and helping others grow and develop their careers. When people are doing role and they're going down the wrong path, course correcting them, but also then having a positive influence, giving positive aspects of, this is great, keep doing it, you're doing the right things, as well as highlighting the things that not quite so good. Maybe that wasn't the greatest way of approaching things and helping coach them to do the right thing and succeed. It depends on what kind of organization you're in. So some of the other things that managers often get involved in is the project plan and the negotiation with other teams and budgeting and things like that. And then there's those seniority levels. As a manager, as you move like senior manager director, you're getting into territory of a much bigger impact, broader impact, and less engaged with engineers. When you've begun talks about becoming a manager, actually formalizing this was where you're afraid of what turned out to be true or not. And what would you say to yourself from that to 2006 today? Maybe it's worth touching on how things have evolved as well as managers. So in the early days, and you still get a little bit of this, it was like you've heard the concept of command and control. Often people move into management because they feel they want to have control of things. There is still a level of that. Even for me, I like seeing that am I in control of the situation? And my anxiety levels go up, if I don't feel like there's some level of control and things are not going the way you kind of expected it. So you've got a blended role, which is as a manager, you probably want to have some level of control over things. And in the early days, it was very much about laying out a plan and let's execute to this plan and making mistakes like micromanaging, being involved in people, telling them what to do is the biggest mistake you can make as a manager. And if I was to give advice to people moving into management, that really is, that's a cardinal sin kind of thing. Just don't go there. You may know engineering, you may know how to code, but the best thing you can do for your engineering team is show leadership, which is enable people to think about the right way of doing it without telling people how to do it and also make mistakes. Yeah, exactly. And that's where I was going to go next. You've got to be willing to allow people to safely make mistakes. And you know, people are safe. Yeah. And safety is that you've got the other things you hear is like managers should provide top cover, you know, to be a protector of your team. Right. And it's kind of different because you can sometimes get the tension as a manager of you're going to be expected to deliver results. Amazon has deliver results, there's going to be pressure to deliver results. One of their leadership principles. Exactly. And so you can get pressure to do that because you're going to have stakeholders, you're going to have timelines, but it's also protecting the team to enable them to also like, you know, we do learn and be curious. And hopefully within our teams, we still have those, you know, you get time allocated to develop and grow yourself. Right. And that's an enabler of a manager as well. You know, you've got to get the right balance of time. It's understanding the right time to apply pressure and the right time to back off and give and protect the team to allow them to recuperate. You know, you we see it here, you observe the flows of really hard work, really hard work. It's always hard work, but we try to give time to recuperate and think about yourselves, think about your careers as engineers. We talk about goals a lot here. So we're going to have a goal or we're going to have a theme. And this is like in six months time, we want you to deliver X or Y. So this project needs to be delivered by this date. As a manager, your job really is then to set milestones to ensure the pace is there. So trust and verify is something you hear at Amazon. It like it's it's not a leadership principle. But you know, I trust in the team to deliver, but I'm going to verify. And how do I verify? So I use mechanisms to verify. And Amazon talks about mechanisms of, you know, what charts can I look at? So I know the needles moving. So in agile, we talk about burn down charts. Exactly. And, you know, is the burn down chart going well? Are we meeting milestones? So I've set the mission. And I shouldn't be there. Should be micromanaging. Oh, what have you done this task? And why haven't you done that task? So you should be allowed to know what the user story is or the theme is on the mission, what that is. And then you break down your work, how you're going to technically deliver it, and you execute on it. I don't need to know the details of what design pattern did you use. And in some ways, I can have an opinion, which is some of the verify that, you know, bounce the idea out there and say, why didn't we use this pattern? Okay, and you have to be able to defend it. Yeah. And then you question your own judgment. Did you, did you actually go the right way? Right. And if you can defend it, okay, you are more enforced in this position. Yeah. Right. By the way, maybe we should go around and figure it again. Yeah. So, you know, do iterations. And that's part of that. That's why, you know, we tend to be agile here at Amazon is because it allows you to get the feedback loop and an early feedback loop was we successful. So, you know, we talked about safety again. Knowing that you can safely deliver it in a period of time. Right. And then we adjust the project plans. You know, if we're not, if we're not moving at a pace in a complexity could be higher than we expected, we shouldn't keep driving to meet that date. It's about let's move the date out. So that's the manager's job is to then go and negotiate with the stakeholders and say, we might have to move a load of other project plans, because people are dependent upon us to deliver something on occasions, we just like it's going to be impossible to meet that date. We bring people in and that's to help get it back on track, because sometimes that date's removable. Yeah. And, you know, we have to make compromises and it's the manager's job to get from the engineers what compromises can we make. And that could be, you know, maybe we're not going to insist on high standards to the degree that we would always want to. Right. And then we have to consider how we're going to pay that technical debt off. At what point do I need to pay this off to get us back on track to have a high quality product and constantly evolving that product? Would you consider going back? If I could go back in time, I would probably, for me personally, it's such a hard question, would I? Part of me says, yeah, I would love to go back to being what I would call an individual contributor, just a coder. But then there's that other part of me likes to see the bigger picture and be involved in the bigger picture. And you can do that as a senior level in an engineering realm. And then would I miss that helping people grow? And even so, you know, even as a senior engineer, you're involved in hard development, the best we see it, you know, we constantly encourage people. Yeah, a graduate comes in, even as a relatively new member of the Amazon community, you're encouraged to help them grow and develop as well, because everybody wants to see the next person succeed. Exactly. And, you know, and see them grow and contribute to the team because that's how we scale and accomplish how much we do accomplish. Because it's not all dependent upon one person, it's like a cell, we want to multiply. When you multiply, you become stronger. Right. From what you're saying, there's a lot of things to be gained from this position. So we would recommend it to people like that are considering switching transition. Yeah, like you need to be sure about what values is it that are important to you, you know, so if you're in Amazon, you look at our leadership principles. And even if you're not in Amazon, you can look at the Amazon leadership principles and then ask the question, well, what would be expected of me as a manager? What are the leadership principles that are going to be different to what I'm doing as an engineer? What key traits or features of or character should have this person that is transitioning to this role? So it's going to lead to some degree and trust. You know, can you earn the trust of your colleagues and team members? Can you also think big? Can you think beyond the horizon? And so not shine away from like being the one who's pushing the team and all thinking, why doesn't Gary get it? Why is Gary pushing us as this without turning around to everyone and saying, no, we need to do this because of this, because that's if I'm telling you what to do, that's command and control again. And I could be wrong. So our right a lot comes into play here because Amazon has a tremendous number of very, very clever people with lots of different ideas and ways of approaching things. And as a manager, you've got to be willing to let go and let them come up with the ideas. You add it to your own ideas and encourage everybody's collectively to move us to a better position. As a team, we're in a better position on one individual saying, this is how we should do it. And hopefully you've seen that within our team. So we constantly challenge each other. We constantly have discussions. We do design reviews. We never accept the fact that the first design is going to be perfect. Yes, it's very hard to get the first one right. Yeah. Have we ever had that? Well, I haven't been. Thanks so much for joining us here and having coffee with Smok. I hope that you enjoyed this short interview. It's now your privilege to nominate next person, to invite him together to next episode of having coffee with Smok. Who do we pick? Maybe try one of the product managers. So let's think of Mac or Conn. Okay, I'm going to do that. Thanks so much. Thank you.