Epod Episode 5: Craig Lee on Technical Project Management

Listen to Episode 5:

[powerpress]

On this Episode:

On this episode, Susan Ottmann talks with Craig Lee—a Principal Group Engineering Manager with Microsoft in Redmond, Washington. Craig completed his Master of Engineering in Engineering Management right here at UW-Madison. In this interview, he provides insights into his learnings from the MEM program, the Technical Project Management course where he serves as a thought-leader, and his experience as a leader at Microsoft. 

Our Guest:

Craig Lee is a graduate of UW-Madison Master of Engineering Management program. He is an experienced leader with over twenty years of experience in the software industry. He has worked for both small to large organizations effectively combining strong technical know-how with the ability to create and communicate a strategic vision. He has proven himself by forming, managing, and leading cross-geo and high-throughput teams and delivering quality on both v1 and established products. Craig was recently promoted to Principal Group Engineering Manager at Microsoft. He has been with Microsoft since 2006, and one of his roles has been the Principle Engineering Manager for the Power PI Interactive Data Visualization platform. He’s also held leadership roles for Microsoft Outlook and Cloud AI Platforms. Craig holds six patents and is a thought leader providing input for current students in the UW-Madison Technical Project Management course that is part of the core UW-Madison Master of Engineering curriculum.

Subscribe to Podcast

 

Transcript 

Justin Kyle Bush: Welcome to Epod, a podcast from the UW-Madison’s College of Engineering’s Office of Interdisciplinary Professional Programs. These podcasts are focused on big ideas and engineering and the people behind them. My name is Justin Kyle Bush, and I am your host.   On today’s episode, Susan Ottmann talks with Craig Lee, who is the principal group engineering manager with Microsoft in Redmond, Washington. Craig completed his Master of Engineering in Engineering Management right here at UW-Madison. He will be providing insights into his learnings from the technical project management course, his program, and his experience as a leader at Microsoft. Take it away, Susan.  [00:00:55] Susan Ottmann: To start the discussion. Craig, please share a bit about your career.   [00:01:02] Craig Lee: Well, first of all, thank you very much, Susan, for having me today. It’s exciting to have this opportunity. So I, I have kind of a roundabout path that I took into the role that I have today. Most, most students are most, uh, uh, colleagues of mine.  [00:01:19] You know, went through the typical computer science degree and internships, and then into the industry. But, you know, I started as a really young age with, you know, fascinated with computers had, uh, our first, my first computer at age 12. And, you know, just spend a lot of time in early years in high school, uh, you know, just really kind of fascinated with that whole PC boom that happened in the, in the eighties. But in the, in the nineties, I decided that for some reason I was going to be a lawyer and kind of took the, got a BA in political science and it was going that route.  [00:01:55] But, um, found myself in, in Seattle, in the mid-nineties and took some side jobs and, and essentially taught myself programming, um, and software engineering and, and started getting consulting jobs and, and other, uh, gigs that then turned into actually full-time software engineering work and work through that different small companies in the Seattle area.  [00:02:23] And then finally made my big transition to Microsoft in 2006. And that was just a lot of, you know, the result of a lot of, a lot of reading and, and on the job training and, and, you know, hard work and self-teaching um, but since then, you know, it’s been a great experience. At Microsoft, you know, it’s such a large company and there’s such a variety of products and services that are offered that I’ve, I feel like even in the almost 15 years I’ve been there, it’s been almost four or five different distinct experiences from developer tools to, you know, working in, on the outlook product, uh, spent some time working on the machine, learning tooling and platforms in dynamics. And then, now I’m in a data governance team working on internal and external privacy, operations and products. Um, and in the, in the transition to Microsoft, I also started off as an individual contributor.  [00:03:27] Um, I had some management experience and prior to that company, uh, but then throughout my career at Microsoft has been a steady growth from, um, you know, from the, in initially individual contributor to small team lead to engineering manager. And then I think to a large degree, based on my experience with men program, uh, over the last year have moved into a manager manager role.  [00:03:56] Um, and that’s currently where I am today and enjoying that, um, these great experiences and challenge.   [00:04:03] Susan Ottmann: Wow, what a fascinating career. And you’ve got a long way to go from here. Today’s podcast is focused on technical project management and its impact on your ability to think strategically with executing projects. What were your biggest takeaways learned from this course that you were able to apply at Microsoft?  [00:04:23] Craig Lee: So one of the, one of the themes that I saw recurring not only in TPM, but also throughout the mem classes, is that how you start is really almost the important part of any endeavor or project. Um, the very specifically, over the last two or three teams that I’ve been on, I’ve actually used the project overview statement template.  [00:04:56] And it’s amazingly clarifying to take that template work through all of the sections, think about the problem and the customers and the goals and the metrics and you know, all of those aspects of the project because it just brings an incredible amount of clarity. I’ve had a number of people as we go through this process, go, wow, this is great.  [00:05:21] I can’t believe all this clarity we’re getting, you know, from actually going through this exercise. So, um, and I just talk all the time with my team about how important it is to have a clear scope and priorities. And we invest a lot of time in those activities and those discussions, because I think having that you know starting strong is so important to being successful because if you start off, uh, it’s really hard to recover. Think another, um, another artist, you know, with, with this recent time with COVID, you know, the, the articles and slides on B teams that we talk about in TPM, I’ve just been going back to those quite frequently and like picking up different aspects of it.  [00:06:07] And, um, one thing that I went back to fairly early and really believe in strongly was the discussion about the benefits of face-to-face meetings. Um, and then how much, even zoom and teams, these technologies don’t fully replicate that experience. And so one thing I set up very early in COVID was a kind of a daily virtual water cooler meeting where we can just get together for 15-20 minutes. And just talk about, you know – the only rule is don’t talk about work.   Uh, but then I’ve also set up what I called social distant lunches, where everybody brings along chair and their lunch, and we gather on campus and just sit in a big circle and eat our lunch and talk. And it’s great to see people, you know, in real space, and you can have side conversations and people can get to know each other and just ways that you just can’t in a large zoom meeting.   So, you know, those two have definitely been super critical. But one thing that I also pulled out of it was the concept of reliable promises. Um, I think in the past, the planning that I’ve done at Microsoft, there’s just, there’s a variety of things that we talk about and if we really dig into it, different parts of our plan have different weight to them.  [00:07:35] Some things we, we really need to get done, there is either strong dependencies or it’s super critical for the business or the customers. And some items are more kind of nice to have or wishful thinking. Um, but we bundle all these things together in a plan. And then it’s, you, you’re almost guaranteed now for the plan to fail because you’ve got all this mix of things.  [00:07:56] And so I’ve started dividing our planning into a core aspect of what the team is going to actually promise to deliver. And we go a much deeper level of investigation and planning in order to come to that decision. And then there are aspects of the plan that aren’t, you know, aren’t to that level. Um, and we, we have them in there cause we want to try to get them done.  [00:08:18] They’re important, but they’re not, they don’t rise to that level. And I think that’s really blot brought a lot of clarity. Especially to my management, when they look at the plans and they can really understand, okay, what are you really committing to versus what are you hoping to get done or thinking that you can get done based on some initial costing.  [00:08:36] And then the final piece is, uh, you know, the discussions on risks and uncertainties, I think is just super critical. Uh, one of the things that I talk about when whenever a new engineer, you know, we hire a lot of engineers right out of, right out of college. And I try to make sure that I spend time drilling this into their brains, that, you know, you have to understand where, you know, when you put together any kind of plan either for your day or for the week for them.  [00:09:08] You know, where are those risks and uncertainties, because there’s going to be aspects of what you’re trying to accomplish that you’ve done before. And maybe they’re, you know, you can completely estimate them to a high degree of confidence, but there’s going to be items of that work that, you know, you maybe have never done.  [00:09:27] And, um, you have to do the work either prototyping or investigation or next level of costing to really identify manage and mitigate those items. Um, and if you’re not doing that, then any plan you build is going to be, you know, kind of a toss up. Uh, so I think I, I find myself going back to like really key, important parts, um, from this class.  [00:09:52] And I think that it’s, it just forms this incredible foundation of knowledge and, and, um, awareness for any types of.   [00:10:04] Susan Ottmann: Thank you. You’ve picked some of the, my favorite parts of the class, especially reliable, promising. I use that tool a lot. You talk about new engineers, joining your team. What about those who are become new technical project managers? What advice would you give them suggestions or tips for someone who is new at leading projects?   [00:10:24] Craig Lee: I think that the, the key, the key thing I would say is back to the earlier discussion to just really make sure that you start strong. Um, and I think it comes from a couple of, I think we’ll talk about three different angles on this.  [00:10:40] One. One is, you know, understand your business and the goals of your management to really make sure that the project aligns strategically with with those, um, the worst case scenario to be in, especially as a new project manager, is to be given a project that either your boss doesn’t think is important or your boss’s boss doesn’t think is important, or isn’t actually clearly aligned with strategy of the organization, because then you’re just, it just I’ve been in that situation.  [00:11:14] And it just feels like you’re constantly rowing upriver. Um, so really make sure that you, as much as you can pick projects that are aligned. The second is to be very clear upfront what the scope, priority and scope and priority are. And then like we just discussed do the work to really understand the risks and uncertainties.  [00:11:37] Um, because I think if you can get that clear picture upfront, uh, you can then target your energy because so much about being a good project manager is knowing what to spend your time on. Uh, and I think initially, really focusing and spending as much energy as you can on those items is super important. And the final piece is, is, you know, you’ve, you’ve got to build a great team.  [00:12:03] Um, cause if you do the first two items amazingly well, but the team can’t execute, then you’re kind of stuck as a project manager. So, you know, and think of it both not only individuals that can deliver the business results you’re looking for, but also on and almost equally, or maybe even more importantly, make sure that those people work the way you want to work, you know, make sure that, that you all enjoy being around them, that they they’ve the culture of, of how they treat people and, and just make sure you, you think about both capability as well as.  [00:12:39] Uh, you know, how they interact with people and how they work, because the worst thing that can happen with the team as you put this team together, and you’ve got one person that’s either very negative or, you know, not aligned and they can really, it’s amazing how one person can do so much damage to productivity.  [00:13:00] So I think paying attention to those top three things is the, the key to get going.   [00:13:06] Susan Ottmann: Well, congratulations on your recent promotion. So now you’re a step above a project manager and are looking at portfolio of projects that your team is managing. Do you have specific methods to deploy your different resources or how are your individuals dedicated to projects? Are they cycled through or are they using, um, subject matter experts? Can you talk just a little bit about that portfolio and how you use your resources in your team?   [00:13:36] Craig Lee: Sure. Microsoft has been going through this fundamental shift in almost all aspects of their business from, you know, a company that was built on, you know, writing software and shipping it on disks and CDs to, you know, running top rating cloud services, um, and engineers at Microsoft.  [00:13:57] Now today are, are expected to build, deploy, operate, and support our products. I mean, we are, we are offering these cloud services to companies and, you know, they expect them to work as, you know, 24/7, you know, with a great support and new functionality. Um, and so what we, the model that we’ve kind of moved to is we end up with one or more.  [00:14:24] Engineering managers that get assigned to a given service. Um, and you know, those engineering managers have a very clear charter and ownership. It’s like they, they are, you know, there’s a very distinct, clear line between different services. Um, and they’re able to then, you know, do that full life cycle with when internally Microsoft is calling dev ups  [00:14:49] Both development and operations, um, together. Um, from my team, we have, uh, we have a few internal services that manage the, the capabilities inside the company for privacy and regulation compliance of, of private data and personal data. And then we also have some, uh, external products that we’re building.  [00:15:17] And so the engineering managers end up being assigned to the various services. So I have, uh, three engineering managers that are assigned to one, uh, service and a set of scenarios and products. And then a couple other engineering managers that are focus on different aspects of the new capabilities that we’re building.  [00:15:41] So they end up being very much, uh, targeted to an external deliverable. Um, as far as charter and, and ownership, um.  [00:15:58] Then as far as the individual funding, you know, how big should each team be and where should the engineers be, be placed? Um, the, I give an engineering manager has, uh, a set of people, a set of engineers that are really the level of that funding is really geared toward again, the product or service that they’re managing.  [00:16:23] But, the work on a month to month, or an iterate, a sprint to sprint basis is a combination of work that is both servicing existing products, as well as thinking about new functionality. So, we need to kind of fund both. We need to figure out that, you know, how many people do we need to kind of keep things running and keep high support and, and service.  [00:16:46] And how many people can be allocated toward new development, um, functionality. So that’s kind of a first level planning that we do. And then as far as the, you know, what new work should we focus on? We, we have established, uh, different pillars of scenarios and functionality that are aligned to different business metrics and business outcomes.  [00:17:13] And we, we do is, uh, you know, kind of a simple budgeting exercise at the beginning of a planning cycle where we say, okay, how much do we want to spend in each of these pillars? And we do some, you know, based on different criteria, we make those decisions. Uh, and then we start looking at the backlogs of each of these pillars and we do a prioritization exercise to understand, okay, what is the most important investments we should be making in these different strategic pillars.   [00:17:42 ]And then based on that outcome, we understand, okay, what work streams do we need to fund on an iteration or sprint by sprint basis? And then the, then the final piece is, okay, well, how does it give an engineer get assigned to these different work streams? And one of the, one of the aspects that I, that we, that I talk a lot about with my engineering managers is that.  [00:18:10] You know, growth and challenging work is super important to, to an engineer’s career, as well as retention and happiness and all these different factors that kind of go into managing people. Um, and so we try to you know, have a, have a real open conversation with the engineers and we try to, you know, the perfect alignment is I talk about the, there’s like three points of a triangle, right?  [00:18:35] There’s the, there’s the business? What does the business need us to get done? There’s the project or the product, what does the product really need to get done? And then the person, what does the engineer need? What challenges and goals do they have? And when we can find a project that meets all three, then that’s like the best of all worlds.  [00:18:57] And, and so we try hard to make sure that we are very transparent with the plan to all of the engineers and let them know, you know, this is what’s happening and this is what’s coming and then work with them to see where can we get maximum alignment and make sure that everybody feels like they’re getting a challenging assignment that’s helping them grow and helping them meet their career.   [00:19:21] Susan Ottmann: I find it so fascinating. Cause sometimes the company would just look at the business outcomes, but if you don’t look at the people and stretching the people and keeping their ideas fresh and their learning fresh, then those people are going to go to a different company and there’s a lot of companies out there.  So to keep that top talent, you need to have that triangle, not just a flatline.   [00:19:42] Craig Lee: Exactly. Yeah.  [00:19:44] Susan Ottmann:  We are seeing more and more of our students companies move from a traditional waterfall management to the agile environment. I know that you’ve managed agile projects for a long time. How have you seen it successfully applied in deliverables realized?   [00:20:00] Craig Lee: I mean, I guess the, I mean, my, my journey with agile has been, um, from the very beginning, when I, when I was first reading about it and first learning about it. Uh, I very much was under the assumption that, you know, you’ve got to just basically follow the manual. Right. It’s like read the book about scrum or read the book about Patreon programming, or read the book about Kanban and like apply it and everything will be great, right?  [00:20:32] And early on, I remember going to a seminar, um, in the Seattle area and it was, uh, the guy had written an extreme programming book. I can’t remember his name off hand. Uh, and it was just kind of a, a room and we were just asking him questions. Um, and there was one person there and they were from, I won’t say the company’s name, but a very large security company that everybody knows.  [00:20:57] And they said we had, we were going to build a new version of our product and we decided to follow your book.  So we followed every letter of this book. And after a year, the project crashed and burned. It was a complete failure. And he talked about various aspects of what went wrong and how it went wrong. And the author looked at him and said, well, you obviously didn’t do everything.  [00:21:24] You didn’t apply the book correctly, right? So, so there’s this belief, I think in some parts of the agile community that, uh, you know, this will just cure every hill, but the reality is that it won’t. Um, and in, and I think I will even go strong to say, if you do attempt to just blindly apply, you know, one of these approaches, you will probably fail.  [00:21:52] So instead, what I would recommend is, and I think this is true for every aspect. Um, you know, eventually you’ll go through the process, improvement class, and I, I, you know, think about projects it’s, it’s like in every aspect, I think small incremental improvements toward a goal are really the way to go. So what are some things that you can do very practically?  [00:22:14] I think, um, instead, and then it’s almost like a broken record, but I mean, be very clear when you go in about the scope and priority of what you’re trying to accomplish, because I think again, that’s sets everything up for success. And I think it’s the next thing is really think about how do you move to incrementally faster cycles.  [00:22:36] So maybe right now, your, you know, your projects are six months long or whatever – you know, some classic waterfall, you know, the long projects – convinced your management to drop that in half. And, and, and it’s not just dropping in half, but then say, well, the benefit is we’ll get to be able to check in with the customer now.  [00:22:58] Half and half the time and see what they think and make sure that we don’t get all the way to the end and have it be wrong. So again, just think about moving to faster cycles. Um, and again, the big, and I think the reason why we want to move to faster cycles is the, the key insight I think, across all of agile is just the realization that, you know, no one can accurately predict that they’re true.  [00:23:26] You know, unless you’re working on a project that is exactly the same that you’ve done 10 times and you know exactly what’s going to come and you’ve dealt with all of the potential things that could go wrong in the past. Um, if you’re doing anything that is all new or in, uh, even some projects, uh, that could be in a new geography or a new place with different conditions, um, you just really can’t predict the future out more than, you know, weeks or months.  [00:23:57] So, uh, make sure you’re moving in these faster cycles and, uh, try to make, as you go forward constant, but small adjustments to your trajectory. And I think if you, if you adopt those two aspects of agile, you can layer on any type of methodology, um, you know, if you like common boards or if you like sprint boards, if you like story points, or if you like some other aspect of agile, I think you can kind of use whatever you, you feel like your organization can tolerate.  [00:24:33] And, you know, can embrace, but as long as you’re reducing, moving to faster cycle times and you’re constantly checking in with the customer and making small adjustments, I think you’ll, you’ll get the most of the benefit of the agile methodology.   [00:24:58] Susan Ottmann: One term we’ve started used using in our organization at the university is learn our way forward. And I think as you transition from sort of the geometric style of waterfall, project management and move to an agile world, you need to learn. So it can’t be A then B, a completely separate process. It’s not like I’m implementing a new production line in a new facility. You need to learn how to do it and adjust. So that’s some great insights. Before we finish, is there anything else that we’ve missed that you’d like to add for those who are listening to this podcast?   [00:25:31] Craig Lee: Sure. I am not sure why, but I think way too much about the McGregor article that we read in EPD 710. And if you’ve forgotten about it, or if you kind of breezed over it, I would highly recommend you go back and reread it again.  [00:25:47] Um, I just really, really, I think it, I’m not sure if it’s a hyperbole or whether it’s actually true, uh, you know, accurate reflection of reality, but regardless, I really love the point of view in that article that, um, and maybe just a quick recap for those who don’t remember it, it’s, there’s a, there’s a man who is the leader of a  [00:26:09] Of a plant and the interviewer is shocked because he’s basically not involved in the decision-making at the detailed level. He’s just spending his time thinking and planning about the future. And he talks about how all of the, his reports are completely self, uh, self-empowered and, and, and he actively chooses not to make any decisions for his subordinates, you know, and kind of forces them to learn and grow.  [00:26:39] And I, and I think that, and I think that approach, uh, I’m trying it in small pieces and I’m just starting to see a lot of benefit. Uh, and I think it boils down to a couple of key things. One is, you know, really think deeply about your role in the organization. Um, and in any, in any role either, you know, you’re a project manager or a manager or a manager manager, or whatever your, you know, your, where you’re at now and where you’re going. In those roles, you’ll find that there are, you know, distinct problems that you’re able to solve.  [00:27:20] Um, either through your, your ability or your position in the organization. Um, and especially when you, when you make the first transition to manager, uh, the number one thing that trips people up as they, as they keep doing the job they were doing, but they start managing people. And then that just leads to bad micromanagement and lack of empowerment and people be getting upset.  [00:27:45] But, and so instead think about, you know, now you’re a manager or now you’re a project manager. What problems can you distinctly tackle? Um, and then I think that the correlated to that is actively avoid solving the problems that others have been hired or are equipped to solve. Um, I think that that really gives you  [00:28:17] as a, as a person in a new role or even an existing role, I think that gives you the space to be challenged and to grow because you’re not dipping your hands down into the details of what you used to do, but you’re trying to kind of reach up to the new things that you could be doing. And I think it also empowers people, um, at their level to, to really be challenged and grow. Um, so I think I, that, I don’t know why I just find myself going back and reading that probably every few months, uh, and getting something new out of it.  [00:28:55] But I just think that that frame is like super important. Um, especially as you go through your career and you kind of, uh, grow into different roles, um, finding that place where you can add unique value is super important.  [00:29:14] Susan Ottmann: Well, Craig, this has been such an interesting session and we want to thank you so much for your time.  [00:29:19] Justin Kyle Bush: Thank you for listening to Epod. For more episodes, visit www.sandbox.interpro.wisc.edu/podcasts. And if you enjoyed this, don’t forget to subscribe, rate, review, and share.