The People, Process, & Progress Podcast - How Technical Should Project Managers Really Be? | S4Ep17

Episode Date: February 7, 2025

Hello everyone and welcome back to The People, Process, & Progress Podcast, I’m your host Kevin Pannell. On today’s episode, How Technical Should Project Managers Really Be? | S4Ep17 I’m speaking to Project Managers, aspiring PMs, team leads, and anyone involved in software or technical projects. My goal is to talk through the optimal level of technical understanding for project managers, emphasizing the value of technical literacy without overstepping into solution design, and balancing tactical involvement with strategic oversight.

Hello, everyone, and welcome back to the People, Process, and Progress podcast. I'm your host, Kevin Pinnell, and on today's episode, How Technical Should Project Managers Really Be, Season 4, Episode 17, I'm speaking to project managers, aspiring PMs, team leads, and anyone involved in software and technical projects. My goal is to talk through the optimal level of technical understanding for project managers, emphasizing the value of technical literacy without overstepping into solution design and balancing tactical involvement with strategic oversight. But first, let's set the ground rules. Please silence your cell phones, hold all sidebar conversations to a minimum,

and let's get started with the People Process Progress Podcast. podcast. I started my information technology career pulling PC towers from under desks, manually saving favorites and files from one hard drive, installing a fresh copy of Windows, whatever version, then recopying all the files back onto the fresh operating system. As my IT career grew, I became a tech in the field, then an IT support manager, and I needed to maintain my technical skills to provide the best service to my customers. That was my job. Decades later, as a project manager and a leader of project managers, I found and find myself calling on my old technical skills and at times struggling

with chiming in on technical solutions when it may have been or could be more effective stepping back and facilitating conversations. So for today's episodes, how technical should PMs actually be? Let's talk through four focus areas of the value of technical literacy, avoiding the solver trap, balancing tactical versus strategic, and how non-technical PMs can learn from their more technically inclined team members. So section one, the value of technical literacy for project managers. What is technical literacy? Let's just talk about that for project managers. So to me, technical literacy is not about coding or deep engineering, but it's understanding core concepts, the technologies involved in the project, like how a PC or laptop prints, the basics of network

topology, how key software in your business is configured, and the ever-important awareness of information security policies and procedures. So what's the landscape of the tech you have? Do you know how to use it? Certainly the core PM skillsets, not necessarily talking about that Excel, Office, Agile, like whatever tool you use. So why is technical literacy crucial? I found that having some technical literacy, even competency in some areas, can and has improved my communication with technical teams.

It provided me and other project managers the ability to speak the tech subject matter experts or SMEs language, understand their challenges, and ask more informed questions. Additionally, it improves relationships and communication, this literacy or competency or familiarity, it lets project managers provide more accurate estimations as well, right, which in turn then gives the team better grasp of the effort or often the assumed effort, which happens early in projects, as we all know,

involved in the technical tasks. And also knowing a bit about tech, it helps project managers enhance our risk assessment abilities, right? If I know kind of all the tech we're trying to put together, I can be aware of the tech in and around my space and kind of identify potential roadblocks, right, or developing mitigation strategies and start to put those together. Of course, and as I talked to that in other sections here, we're going to talk to those subject matter experts anyway. And then additionally, why it's crucial, why technical literacy is crucial for PMs, it's one of the most important benefits

is being tech savvy, is increased credibility with stakeholders, right? If we can think of the initial discussions with vendors when they've showed us their miracle solution, if you drop as a project manager a technically informed question, the discussion demonstrates that you kind of have an understanding like, oh, he kind of knows about this world,

right? And at least that you're more than a note taker and a task updater. And I think that's important to kind of throw that up there, throw a sign up that's like, hey, I kind of know some things, even though I'm here to help facilitate this process. So, you know, for me, there is value in technical literacy. And in this section two, let's talk about the solver trap, right? When technical knowledge can become a hindrance for project managers. Why is it not a good idea for us as project managers to put ourselves into technical problem solver mode? Well, when we dive into the tactical aspects of the projects, I think it distracts from our core PM responsibilities.

And to me, I'm going to share what I think a mission statement is for project managers across the world. And it's to provide process facilitation, relationship management, and transparent reporting of projects so that the project team is highly functional, team members are engaged, and stakeholders at all levels are aware of what is happening with the project and the direction that it's headed. So if we're mired in troubleshooting mode, it's hard for us as PMs to meet our own mission statement, right? If we accept that that's what we're going to focus on. And the thing is, you know, if we're asked for technical subject matter experts or SMEs, we ask for them for a reason, right? Not so we could have them there and then we just start throwing out a bunch of solutions. If we constantly problem solve, we can undermine their expertise and ownership.

So instead, we need to queue up questions that allows the team, you know, to be aware of what done looks like, and we're letting them know and then step back and let them build the plan and the solution. That's that's why they're on the team. Additionally, if we put ourselves in this solver loop, we're losing focus to the big picture, right? And we're undermining those technical folks. And it can lead to suboptimal solutions, right? Because we're not the expert in that field, or typically we're not. Now, I say this with a caveat, there are projects and project management fields, or at least postings and different things where I've seen you have to be an engineer, you have to be construction like this and that, that's maybe a little bit different. But I find overall in the industry, project managers shouldn't be down in the weeds. That's why you want them, you want them out of it, right? And so we often may not have that deep technical expertise in the area. And even if we do, if we're asked to come in as a project manager, that's not our J-O-B. So how do we resist this urge to solve problems? So one, recognize and self reaffirm your role as a facilitator, and a communicator. And the thing

I thought of, and I'm going to share now was, you know, if you're old enough, and you know, who Stuart Smalley is, he's from the 90s. It's Al Franken, the character who did of Saturday Night Live, I want you to look in the mirror as a project manager and say, I'm good enough. I'm smart enough. And doggone it, I'm the project manager, not the analyst. If you're too young to remember that, Google it, Stuart Smiley. It's worth it. There's plenty of funny videos. So we need to trust, too, the technical expertise on our team, right? It's one of the most important things that a project manager can do. Empower the team, then listen to them. Then if you hear something that's like way off, ask a clarifying question because you may just not understand what they've said or how they've said it. 100% do that. And that also gives you

some credibility, some project cred that I don't know. I need to get comfortable with that. And I mentioned that here in a second. But, you know, asking those instead of offering solutions constantly is a great way to coach the team. Remember, coaching is I'm asking you questions towards success without consulting them or problem, you know, solution, solution, solution to death with your technical guidance or what you think is your technical guidance. Because, again, if you don't really know that area, you're not really helping. So the other thing we can do, if we're kind of stuck in this loop, or help us not be in this loop of trying to solve the problem for our team, is make sure that we've clearly defined the problem, right? We know the team knows what they're trying to solve, because they might be confused. And we're thinking, Oh, I have to solve it, because you don't know what you're talking about. If not, ask the subject matter experts

and make sure we reiterate, here's why we're doing this. Here's why you're here. Here's what I believe you're, you know, going to be able to help us with. And then you tell me if that's, you know, spot on or not. So section three, how do we balance the tactical involvement with strategic oversight? Project managers have to have the big picture. We have to know where we're going, if we're on time, on budget, within scope, is the quality good? What other factors, right? Does it align with the overall business goal? That's paramount importance for us. So anything that pulls us down from that is a negative to me. So let's talk about the tactical involvement when it's appropriate, right? Sometimes project managers need to understand these competencies and how they

impact the schedule, right? As we build the plan, we need to know the dependencies and how they do or don't align. So again, we're going to have conversations. So we're going to balance, hey, technically, how does this impact our overall schedule? And we're going to talk to our sub-submariner experts and know it takes X amount of time to build a server or upgrade this or that. That's where we need to get into that, right? If we're facilitating, which we are often, communication and collaboration between the teams, then we have to get multiple groups together. We're going to have to have a good statement of what are the technical problems or build or testing or whatever we're trying to

solve. And so project managers, in that instance, do need to be able to articulate the reason for this cross team collaboration, so that, you know, it's appropriate for us to kind of speak the technical speak, right. And, you know, another another opportunity for us when it is appropriate for us to be a little more technical is more track and progress. Right. And potential roadblocks. I kind of mentioned this a second ago. Like, what's the impact of this technical thing to the schedule? But we should ask a lot of questions and get that so we can help do that risk prediction. So how do we stay at the right altitude? How do we balance this? Right.

I'm confused. You say don't get involved, do get involved. Here's, I think, some overarching balancing the tactical and strategic. Again, tactical is ground level, if you will. Strategic is I can see you from 30,000 feet. Delegate tasks, right, to the team members. This is pretty much every task on the project except the PM stuff, right? Like keeping the schedule and tracking the budget and are we in scope and facilitating conversations. Everything else is delegated to the team because

they're the ones that we ask to solve the problem. Another way to stay at the right altitude is focus on high level planning, on risk management. Ask the technical SMEs often to look at, are we on track? Does this still make sense? And sign off on the plans. That also gives them ownership, right? Don't just make the plan and say, here's the plan. Say, here's a draft. Update it with collaboration and the team. And then say, hey, are you all aligned with this?

And then we take it to the sponsor and the business owner. They're like, cool, we sign off. Because you can say, oh, the team made this. We agree. We're aligned. Reduces things. And the team made it, right? We're not SPMs trying to make the plan for them, which isn't our job.

Use PM tools to track the progress, right? We have to do that. So we got to get in tech and whatever system you use, right? Pictures and graphs have helped me and my project teams countless times. If I have the data, I think we as PMs should queue up helpful summaries, which can be pictures, tables, etc. But then we will need to get in the data, get pretty technical with that, right? So we can make sure there's a shared awareness across the board.

Another way for us to balance the right tactical versus strategic is regularly communicate with stakeholders, like the status. We can get a feel for them if it's too much. Are we talking too much? Is it too technical? The message, hey, I don't understand what you just said in that message or in the meeting. Have a really good communications plan. Follow it.

And then adjust it to the tools and the tempo that fits the people on the team. So have your plan. Let it guide you. But don't let it make it so you're not dynamic or not agile like you should be. This last section, section four, I want to talk about practical tips where if you're not dynamic or not agile like you should be. This last section, section four, I want to talk about practical tips where if you're not a technical person, like I came up through technology, but I understand not every project manager has done that, right? And so how can we build our technical skills a bit? So fortunately, it's 2025. There are so many technical online courses in any system you could think of,

right? There are industry publications, conferences, and then online or in-person networking opportunities, right? And so take advantage of all of those, the easiest and most accessible for most people that are doing project management is online, right? But don't, you know, don't discount the getting together with folks having that conversation and publications, a lot of those publications are online. Another opportunity to build your technical chops, as it were, as a project manager. And, and really, if you as a project manager to advance your career, you have to embrace continuous learning is to have that mindset, right? And technology is constantly evolving, the project management system or tools is going to evolve or should evolve.

And if not, how do you evolve by staying with the same tool? And I think of note is not just the tools you use, but your soft skills, right? You need to learn about those. How can I be a better communicator? How can I establish relationships? Again, LinkedIn Learning is great. Probably one of the best well-known that has a good body of work there. There's Coursera, Udemy, so many online things, and worth the money to put into it.

So talk to your PM, a manager, director, whatever leadership about reimbursement, right? Often leaders will pay for you to get professional education, or if you have internal stuff. Another great and probably one of the most important ways is build good relationships with the technical folks on your team, right? So it's during the project after after the project, regular time. But particularly if you're brought in, build a solid relationship and learn from them. Ask them questions. Foster that open communication.

Mutual respect, right, is critical. I don't know. I've never done this. I can help pull folks together. But can you explain to me the methodology or the technology or how this works? You know, can we walk through a diagram of the system? Whatever it is. I've learned so much from my technical subject matter experts

and it's been so helpful for myself professionally and just really, it makes me a better project manager because then I can carry on that knowledge to other projects. And I'll say too, and I mentioned this a few minutes ago, don't be afraid to say, I don't know, right? And then learn, formulate good questions and say I don't know, right? And then learn formulate good questions. And elicit, you know, this useful information without overstepping as you carry

that forward. And I've seen where project managers are afraid to admit what they don't know. But that's the joy of being the project manager, the expectation isn't that you're going to solve the technical problem. So embrace it. Embrace the I don't know mantra or I don't know, but I'll find out. I don't know. Can you please help me? You know, there's a follow-up too. So it's not just an end statement saying you don't know. It's that I'm going to follow up and try and fill that gap of knowledge.

I hope I've shared the value of technical literacy for project managers, the pitfalls and some strategies to avoid the solver trap that we can have as project managers, particularly if we do have a technical background, ways to balance the tactical and strategic involvement that we will have with projects, and some practical tips for how you can enhance your technical understanding, which again, is an ongoing thing and should be for us as project managers. Thank you all for listening to how technical should project managers really be. And whether you're breaking into the project management field or you're salty project management veteran, it's important to find that right balance, right? Of technical knowledge with

process facilitation. Thank you so much for taking 15 minutes out of your day for listening to me as I facilitated this episode. Please go to peopleprocessprogress.com for more episodes, articles, and contact me there. Follow me on, uh, in the podcast on X and Ig at Penel KG. Follow me on LinkedIn. Feel free to connect and visit the Penel 5 Fitness Club YouTube channel, where I share fitness 15 seconds at a time.

There's some cold plunge videos and Brazilian Jiu Jitsu class after action reports for everybody that's out there getting after it. And again, project managers, in addition to all the stuff we talked about today, take care of yourself and your health physically and mentally. Until next time, this is Kevin Pinnell reminding myself and each of you,

keep your hope alive as it ignites your passion, create actionable plans to guide your teams, and take action to transform yourself and those around you for the better. Godspeed, y'all.