Hands-On Leadership vs Empowering Software Engineers

Transcript is auto-generated and may contain errors.

Hey folks, we're going to LinkedIn messages for another question. This is from someone who's trying to go into a TPM role, so technical program manager. And this is a second of two questions. Um, this says, "Since you create so much content on reducing barriers for software engineers, I'm curious, what's one AI powered process or tool you'd recommend a TPM explore first to get real traction?" Um, this question is a little weird for me only because it's generic and I don't know what direction they want me to go with it. Um, so for example, what tool or process do I recommend a TPM explore first to get real traction? Um, traction on what? Like traction on AI tools or traction on engineering, you know, things that TPMs are going to be involved in. and I I think that's the direction uh that they're interested in, but I cannot tell.

It's one of the challenges with questions being submitted that are kind of generic. So, first thing I'll say is that for AI processes and tools, um because we're talking about the workplace, this is going to be restricted to what you have access to at work. This is very important. Um I work at Microsoft, right? I'm not here to sell you co-pilot licenses. Um I don't get commission on that. That'd be kind of cool, but it's not a thing. Um, so, um, we have co-pilot at Microsoft, so I have, you know, sort of the luxury of having access to this kind of stuff, but you need to make sure that whatever you're using at work is approved by it. And I say that because somehow people are still like completely neglecting this. You don't want to be using like your personal chat GPT account and then taking work documents and being like, "Hey, like go do this chat GPT." like that is a huge no.

Don't um do what your IT department has approved. Um so like I can't I can't give someone a specific tool because it's like I use co-pilot at work because that's what we have. The point that I want to make here is for whatever AI tools, use what is approved because you will have significantly bigger problems if you are just like leaking out proprietary stuff into different LLMs. Don't um so if you're not sure, go have a talk with someone from IT at work. Uh, and I'm sure that this has been something on their their radar if it's not already done about how um, you know, what kind of safety and security policies they're putting in place for AI tools. So, um, I'm going to try to talk about this a little bit more generically because I can't just talk about a specific tool uh, because it's just going to be co-pilot because that's what we got at work.

So um my thought process around this is like if you are trying to as a TPM get a better understanding of an area um that might be more technical. My approach cuz this is would be kind of what I do as an engineering manager is like I need to start at a high level and then start zooming in. And the what I'm going to talk through here is not like it's not rocket surgery. I didn't like invent this. It's not special. I'm just kind of sharing like this is just what I do. Um, so if you're like, "Hey, Nick, like that seems pretty obvious to me." Like, great, that's cool. Then we're probably aligned on this stuff. Um, but, uh, I start at a high level and I think that one of the the great powers we get with LLMs is like you don't need to know all the keywords, right?

Traditionally, when we're searching for stuff, it can you imagine you're new to a team and you're like, I need to know the keywords to go search so that I can start pulling back chunks of documents to go, hm, is this relevant. Now, you have to go sifting and pulling the data. And it's a bit of a pain in the ass, right? Especially if you don't know the keywords. Like, that's the whole challenge. Uh whereas with uh LLMs, it's a lot more semantic. So you can describe something and it can try to figure out what you mean. It's not bulletproof, of course. We all know this with AI, I hope. Uh it's not uh it's not always going to be perfect. It rarely is. So uh the difference though is that it like it pulls the stuff back for you, right? Not like here's a list of stuff, you sift through it, it pulls back stuff for you.

Um, one other risk with this though is that um, if you are more experienced or you have a little bit more domain knowledge when you are keyword searching and getting results, um, one of the things with documentation is that like it's almost always out of date. So, when you're looking through stuff and it references a document and you're like, oh, like I know this one's out of date or like I can tell from how this architecture is being described. We don't do that anymore. Like you can automatically just kind of exclude that. Whereas with LLMs, like because it's pulling back stuff for you and summarizing, like you kind of miss that opportunity and you might get a summary of something that is based on something that's at a date and not accurate. now.

So, it's a bit of a trade-off, but one of the meta points that I wanted to bring up for answering this question is like in order for these processes to work effectively, I think that it's very important that um one you have uh your documentation of whatever format hooked up so that the whatever AI tooling you're using at work can search through it. So again, something like C-pilot, like because we're at Microsoft, we have this sort of again like this luxury as employees there where our stuff is uh indexed, it can be picked up by C-pilot. If you don't have Copilot, like whatever tool you're using, make sure that the stuff that you want to have access to through the LLM is available to the LLM. Sounds kind of obvious. Um but like maybe I'm just making this up. Maybe all of your stuff is in Jira.

Um I I know a lot of people hate Jira. I used to love using Jira. just to record information, right? We do a lot of like uh in digital forensics, we'd be investigating like uh not performing an investigation, but like researching a technology or something, we'd go write it up in the Jira tickets. That was like a spot for us to go keep information. So, knowing that like if you if you're using LLMs, if like if your LLM can't access Jira, then like for us that would have been a very limiting factor for pulling information back. So, um you do you have an internal wiki? Do you have uh like uh word documents, PDFs, like whatever it happens to be? Get your LLM hooked up to that. And then documentation needs to be up to date. Critical. Um but it's also challenging because everyone wants up-to-date documentation.

No one wants to be the person to do it, right? Um, everyone is pissed off when there is no documentation and then so you go make it, someone goes and makes it, everyone's like, "Yeah, problem solved." But it's not because documentation carries a tax and that means that someone has to pay the tax of keeping it up to date. So, um, you need LLM to have access to the stuff and documentation needs to be up to date. Um, if you can get those two things working really well, then you'll get better and better results when doing this kind of stuff. But all of that said, um if you can have your team uh sort of work towards those goals, it's never going to be perfect. That's fine. My approach is really start high level. Um I recorded a version of this before and didn't turn my mic on like an idiot.

So the example I tried to walk through was like assume that your team is building like and it's going to be even worse the second time through. Assume your team is building a calendar app and you're the TPM for it. and um there's like a a booking or like scheduling feature and um you're like cool okay well if we're going to be working on this like I need to understand it better so what I would do is like go to the you know whatever LLM or AI tool you're using and start highlevel asking questions about it so um like when was this integrated like who was working on it so now you can kind of build out a mental model for like maybe who subject matter experts are Um you could like especially on the technical side uh I would start asking about architecture uh

integration points things like that asking it I don't know like if does your LM have access to the codebase like can it start describing highlevel integration points for you um I think that it would be very valuable like getting into like classes and like lines of code probably not um but understanding large building blocks that go into the system I think could be very valuable And an example I can think of here is um you're working with the engineers on this and they're saying hey we have to go touch this module and you're like great go touch the module then and they're like yeah but that module is actually shared like between us and this other team and and whatever and uh if we go make changes to that module and we have to deploy it that's actually going to cause an impact to this other team like we are like it's a shared dependency we actually need to pull them into this conversation.

Um I think what's really valuable is that if you're able to sort of get that high level understanding from these like from building blocks um then those conversations become a little bit more straightforward. So uh I would use AI tools to describe systems high level and interaction points. Um that's I think how I would approach it. Start very high level uh and then start zooming in on building blocks. uh once you're getting into lines of code and classes and stuff, that's probably too far. Um but that's I think in a nutshell how I would look at that kind of stuff. It's like it's a very generic answer like I said, but um if you need more specific knowledge, it's not coming up. One of the reasons I said like even figuring out who worked on this stuff is that great, if the Lam's not helping you, at least you have a contact now.

You can go talk with them. Um, so between your contacts, um, and other conversations that are happening, you might come up with other things that you should be asking the LLM about. But this whole process I'm describing is really just building up a mind map, right? So, this will look different for everyone in terms of how you think through problems and all of that. But for me, it starts there's like some sort of cat hair in my face. Um, for me it's like a high level and I want to kind of go very broad and then start breaking down parts of the system. Um, and that's how like my brain works to map things out. So again, that's my approach. I don't know if there's anything else to add. I feel like this was an AI generated question. Um, I thought it was interesting at least to answer, but that's my approach.

So uh, if you want questions answered, leave them below in the comments. Otherwise, go to codecommute.com. You can submit questions anonymously. And a friendly reminder, there are other YouTube channels that I have. So, if you want car.net and AI programming tutorials, check out Devleader. If you want uh resume reviews and interview prep help, um go to Devleer Path to Tech. And if you are interested in software engineering interviews where you can hear about other people's career journeys as well as the live stream that I run every Monday 700 p.m. Pacific, you can go to the Dev Leader podcast. There are links to all of those in the description. So check them out. I will see you in the next video. Take care.