5 tips for the accidental PM

In this episode of Workflow, Brian and Tom talk about 5 tips for the accidental PM.

00:41     Intro (Recur 2018)
04:06    What is an accidental PM
10:05    Tip #1: Don’t Just Manage - Lead
15:44    Tip #2: Plan collaboratively with your team
20:47   Tip #3: Pick A Process, Any Process
24:45   Tip #4: Focus on the Customers needs
26:32   Tip #5: Keep your promises
31:36   Tips for taking action

Useful Links

Recur 2018
ProfitWell

Tom: 00:00 This is workflow episode 24. Workflow is the podcast that helps teams figure out the best way to work, collaborate and get stuff done. Brought to you by Rindle. Hey, everyone, I'm Tom.

Brian: 00:31 And I'm Brian.

Tom: 00:32 We are the co-founders of Rindle, and this is our podcast, Workflow. Today, we're talking about five tips for the accidental project manager.

Brian: 00:41 Tom, how was Recur? The event that we went to in Boston?

Tom: 00:44 Oh, it was good. It was nice. Smooth ride up there. Unfortunately, nothing had really happened that first night. The year prior, we did a lot of good networking. Met a lot of cool people the night before the actual event, but unfortunately this year no one seemed to be around. But the actual event itself, it was definitely I thought definitely better than last year, which last year was the first year that I had gone. I know you went two years, the past two years in a row, this being your third year, right?

Brian: 01:23 Yep.

Tom: 01:25 But I thought the event itself was a lot better.

Brian: 01:28 Yeah. I thought the production value, in general, was really good. I was really impressed with just the organization of everything. Everything just ran really smoothly. You walked in, you had a really great presentation and you felt we were really in a well-run produced event, which it was. The food was really good, which is always a plus because you're kind of stuck at that event for the whole day. That was good. The talks were I found really good. A couple of one's kind of missed the mark for me. I think some of them also didn't relate to us as much so it wasn't as good, but I'm sure other people got lots of value out of them. But overall I thought it was, we learned a lot, took some takeaways home.

Tom: 02:12 Yeah, I definitely think we'll probably even talk about some of the topics we heard about in this podcast in future weeks. Definitely, really as a whole, definitely much better talks.

Brian: 02:23 Yeah. So we'll go back again next year?

Tom: 02:29 Yeah, maybe. Definitely could see that.

Brian: 02:33 Cool, yeah, join us on a personal note. I'm really pumped that my Christmas shopping is almost done and the wrapping is almost done. And I'll say we're a little over a week out at this point, a week and a half away from Christmas, so I'm super pumped. And by the end of this weekend, hopefully, today's Thursday, so by this weekend and next two or three days, we will be all done. So I'm really pumped about that.

Tom: 03:01 It's pretty exciting. I'm pretty spoiled when it comes to that, as you know. My wife is extremely good at all that stuff and she just basically handles it all.

Brian: 03:12 Pretty awesome. I mean, as you know, you could imagine that I've actually done most of the wrapping to date, but yeah, so I've been working hard and I've been actually doing late night wrapping, which because the kids are in bed and we can do it at night and all this stuff. So it's been last two nights have been hard at work.

Tom: 03:30 Cool. Well, so before we get started with the main topic, if you have any questions, topics, or team scenarios that you want us to tear down, our voicemail is 860-577-2293. Feel free to call in and leave a voicemail and we will definitely respond to you in an episode, or you can also email us at workflowatrindle.com.

Brian: 03:52 Well, great. And also, if you're liking what you're hearing and you're getting some value out of these podcasts, please leave us a review. It helps everything out as far as reliability and other people hearing about us and just keeps us going.

Tom: 04:06 Sure does. Awesome. So the main topic, the accidental PM. I don't even think a lot of people realize that this happens, right? Especially, people that work for large companies or that are on teams, but like a lot of people just end up falling into this project manager role.

Brian: 04:29 I think it's definitely more common than one might think, in general. But also you might not even realize you are an accidental PM because you're not even thinking of yourself as a project manager or something like that. But basically, and it's come up, I think it was a great topic, timely topic at least because we've been talking about accidental PMs here at Rindle for a couple of weeks now really in tune with how it kind of relates to our customer, right?

Brian: 04:55 Because our customers a lot of times are accidental PMs, but these are basically people that never planned to be in a project management role but kind of just fell into it at work. You maybe don't have a PM title, you never kind of set out in your career to be a project manager, but somehow you ended up leading or managing a project along the line. Nor were you ever hired to do this sort of job. It's kind of funny because that literally happened to me, and over time just I guess it crept in. You ended up looking after a couple of projects, managing a couple of projects because they just start to kind of fall on your plate and before you know it you've got a few things rolling.

Tom: 05:38 It could almost be like that you're that person that just was like, "Oh, I'm just open up a product and start to get this organized," like open up some pieces of software and start to get this organized in it. And then all of a sudden you were the project manager. Right? Then everyone just started referring to you as the project manager, which for better or worse that's just how it is sometimes.

Brian: 06:06 Yeah, for me, just my personal experience, because I am probably the definition of an accidental PM, but for me, it happened where I actually had an idea for something in my company. So I wasn't a project manager. I was actually an IT person right where I helped with IT and computer issues and things like that. And I had an idea for a piece of software. Right. So I brought this idea to the company and they're like, "Okay, yeah, you manage it, you deal with it and make it happen. We'll let you go at it." Right. So it just fell on my plate, even from my own recommendation. Right. And they're kind of like, "Okay, yes." I'm like, "Whoa, okay, well now I got to figure this out." Right. What do I do next? I mean I've had some, I guess project experience just because of doing IT projects, so I've led little things here but I never ever officially called myself a product manager or thought I was.

Tom: 06:53 And that happens a lot if you're in a small company, or on a small team or if you're the founder of a company, the responsibility for managing the work it just falls on you. You don't have the budget or the resources to hire an actual formal project manager. So you just got to you got to figure it out.

Brian: 07:15 Yeah. And a lot of times too in those scenarios which I've been into, because sometimes there is no project manager, so obviously, somebody falls into it like yourself. And then there's really no process or anything in place to even start from. Right. So not only are you new to a role potentially, but there's really no guidance a lot of times as to like, "Well, okay, I can do this job and there's a bunch of other people doing this job so I can kind of lean on them." Sometimes you're just on your own, right. You're just kind of figuring it out and just figuring out everything out from the ground up, which is even more challenging at times.

Tom: 07:47 So what do you think the definition for the accidental project manager would be? Something like that you fell into the role and you haven't received any real formal training, and your company doesn't have any real project managers, to begin with.

Brian: 08:03 Well, yeah, I mean, I think it really comes down to you don't call yourself a PM, maybe you have a PM in your title, project manager in your title, maybe you don't, but you certainly have no training. You certainly have no experience. You kind of fell into the role and now you're tasked with leading projects. You fell into it by accident, right? And you never set out in your career to do it and you never have any training in it.

Brian: 08:29 So I think that's really, the definition of it, and there're tons of examples of that out in many different industries. And like you said at the beginning, certified PMs, if you're certified in SCRUM or PMP or whatever it might be, might not even realize so much that this is a thing, right? Because they live in the, "Yes, I'm a project manager, I'm certified and I've been trained in all these things." But for smaller companies, smaller teams, even within bigger companies, I'm sure it's happening, that there are these accidental PMs that just fall into these roles.

Tom: 09:03 And on top of that, I think that there's probably teams within companies that could maybe even benefit from project managers, but they're on some sort of team that traditionally doesn't have a project manager. If someone is actually probably still managing or acting in that role, even if they're, say you're a sales team, but you have some longer term projects for the sales team or a marketing team and you don't have formal project managers like that are supporting you. Someone is still managing the longer term goals. And the longer term things that you have planned.

Brian: 09:37 Yeah. And in developing our product Rindle, we do talk to people all the time and we probably talked to ... The majority of the people that we talk to are "accidental PMs" and once we actually bring up that term, they probably would self-admittedly called themselves accidental PMs.

Tom: 09:55 Sure. You wear it with a badge of honor.

Brian: 09:58 Absolutely.

Tom: 10:00 Awesome. So do we want to get into the actual topic of the tips?

Brian: 10:05 Yeah. So we put together five tips. We'll just go through each one and talk about them. And this really should be, if you are identifying as this, or have been this in the past, these are basically things that could help you along the way from a very high level from day one like, "Oh, I fell into this role, I am this accidental PM. How do I do this? Where do I start?" So these are basically just tips to get you started. Tip number one, don't just manage, lead. This is a big one for me, just because I found a lot of success in my career by leading and not managing. I think it's really challenging. We brought this up before on another podcast episodes as well. But you're looking to gain contributions from your team and buy-in from your team and all of these people don't typically report to you. So for me, that was something I had to learn early on pretty quickly because you're kind of tasked with running a project and you're responsible for it and everybody looks at you when something goes wrong. But all the people that are working with you to make that project happen don't report to you.

Brian: 11:15 That to me was a huge thing and a couple of things that I've kind of did in my career as far as just establishing myself as a, especially early on as a project manager is when you have that project assigned to you or whatever it might be that falls on your plate. You announce to the team like, "This is a project," right? It's not an ad hoc thing. It's not a one-off thing. It's not something that, "Hey, you're helping me out." kind of thing. Like, "This is an actual project," and you're also going to announce that, "I am the one taking ownership of it. I am responsible for it. I am leading this project." Just saying those simple things so everybody's on the same page helps a lot because sometimes I've had assumptions were

Brian: 12:00 People are like, well, Brian's involved, but I'm just kind of going to do my own thing, or he's not really responsible. He's handling the other two people, right? Or whatever it might be.

Brian: 12:08 There's all these assumptions that are made. So for me, in those types of scenarios, especially with a new team, if you haven't worked together before, just establish that. And that kind of resets everybody to be like, okay, I understand now what's going on. And this person is really leading this project.

Tom: 12:22 Yeah, and sometimes this might take the peoples' actual manager to step in and really kind of explain that to the team. Obviously, you kind of hope that wouldn't happen. Because you hope people are mature and adults and kind of understand how these types of things work. Especially if this accidental PM is really the one that's going to be taking responsibility of things go poorly.

Tom: 12:52 It's their job to be running this project. But I think occasionally you'll need management to step in and be like, okay, this person's the lead on this. Like, they're running the show. So you have to listen to them.

Brian: 13:12 Yeah, I've even spelled it out to pp before, too, and I've actually said it, just so it's not the elephant in the room. I've said hey, we're colleagues. You guys don't report to me. I don't report to you. However, I am in charge of this project.

Brian: 13:26 So when it comes down to it, the decision needs to be made, or if there's a problem, the problems come to me. Ultimately some decisions land on me. I'm also the one that's going to take the heat in a lot of ways.

Brian: 13:38 So I make that clear. Being like hey, I know you don't report to me, and you know I don't report to you, and we're cool. We're going to work together. We're a team. I just have a different role there. I try to spell that out. And you're right. I think most of the time, mature people or experienced people, too, will have no problem with this and this won't even be an issue.

Brian: 13:58 But sometimes you just have this kind of disconnect, or people are like, oh, I'm not listening to that person because they're not my boss. You get that kind of thing happening. I just spelled it out a couple times and it's worked well for me.

Tom: 14:10 Yeah. And obviously, I think the people that are more successful at this are people who are better leaders. If you're going to take on this sort of role, you have to be a little bit more, what's the word I'm looking for ... you have to have good people skills. You have to be kind of assertive. And you can't get your feelings hurt too easily.

Brian: 14:31 Yeah, I think most of my success has been around building relationships and I always believe in leading by example. It's hard too, because sometimes you're obviously not executing on the disciplines within a team. So for me, if we're doing software development projects, I'm not a developer. I'm not a designer. I'm not a copywriter. I'm not all of these things, so it's not like I can experience exactly what you guys are going through as a team, or anything like that.

Brian: 14:57 I have a different role and a different set of responsibilities. But I can lead by example, meaning I'm going to come to work every day. I'm going to work hard. I'm going to care about the project. And I think those things alone kind of just rub off on the rest of the team.

Brian: 15:12 And I think that's how I've had success in the past, too, is just that- hey, I'm not your boss. I can't just tell you to care. Nor would that even work. But I can lead by example and show you that hey, I'm here. I'm not going to leave you hanging. I'm going to work hard. I'm going to deal with problems for you. I'm going to help you get what you need to be successful. And I'm hopefully going to make your job easier.

Brian: 15:33 So if we have that understanding and I can prove that to people, that would work really well for me. Because then I earn their respect, essentially. And they will then work with me as opposed to against me.

Tom: 15:44 Cool. So tip number two: plan collaboratively with your team. So I think this could be a mistake that people make, especially with one of their first projects, because you're gung-ho to start this project, and you just start mapping it out in some piece of software. And I think it is a mistake if you silo yourself off and just start planning out the tasks for a project. Obviously you need to have an end game. But that's typically decided by whatever the project is to begin with. The goal is to complete something in the end, or deliver something, or to- maybe the project is to put on some sort of event. There's already an ultimate endgame. But when you actually break that down into the task that needs to be done, you should definitely plan that with your team.

Brian: 16:51 I think especially accidental PMs, or if you're new to that role, I think a lot of people get a project manager's definition, and they will say, okay, I am responsible for planning. And that means this isn't it.

Brian: 17:04 So sometimes you'll go into a silo and be like, okay, this is my job. I've got to get this done. When in the end, obviously, like you're saying, the end results can be better if you include your team. Because actually these are the people who have the expertise in certain areas. These are the people that are going to help execute the project, along with your skill set.

Brian: 17:23 So it's kind of silly even, when you think about it, to kind of like, oh, I'm going to plan this in a silo and expect a whole different group of people to execute it. Which I've seen in my career and I've even done early on, where I make the assumption I'm going to plan it and then I realize quickly that, ugh, I should've included these people earlier.

Brian: 17:42 But yeah, it definitely does alienate your team, too. If you do it in a silo, you're basically saying, you're not important and I don't need you until it's the grunt work time. So it's very non-inclusive. They feel kind of left out and it's not a good morale thing either, for the whole team.

Tom: 17:57 Another point here is that if you alienate your team, you're cutting off the source of your best thinking power. You don't have all the tools to get everything done that needs to be done. So if it's a web design project, you're not a designer, you're not a developer. So you actually need their help to plan this out. You can't just know everything that needs to be done. I mean, especially not unless you've been doing this a lot.

Brian: 18:31 Well, and hopefully the result will be better too.

Tom: 18:33 Sure.

Brian: 18:34 Yeah, and just again, including your team definitely motivates, as I mentioned before, and unites your team. You have a camaraderie that happens when you're like, okay, we're tasked with this thing. We are the team to do it. And they're involved from the planning stage on. I think it just goes a long way. Again, I've seen it both ways, where you're kind of alienating people and it's disconnected, and then timing's off. People don't understand what's going on. And that's another big thing, just within mid-sentence there. Is that when you don't include people in, even from the planning and on, there's a huge disconnect in communication of when things are happening and why. Because people are just off doing something else, because you've excluded them. And then when it's time to come in and execute or do whatever you need them to do, they're kind of like, okay, what's going on? And now you waste a whole bunch more time getting caught up, and if you have a multifaceted team, it could be 5x problem. So yeah, I think that it just makes a ton of sense to include the whole team at the beginning.

Tom: 19:34 Sure, and honestly, I think that it's also going to help with tip number one, establishing your leadership, right? But it will just help people like you more, and it's going to have them trust you more. And also, they're going to feel some sense of responsibility, if you will, to the project, because they helped plan it out. So they know all the steps. They know the reasoning behind the steps and hopefully they agree with them, for the most part. Or else they would've probably mentioned it during this planning process.

Brian: 20:15 Yeah, I mean a big part of project management is trust. You have to have trust in your team and you have to be able to delegate decision-making to your team, too. Every decision isn't yours as a project manager. There are certain decisions that fall within a team, because there are certain levels of expertise and understanding. Things that you don't have. Which is going to make your project, as a project manager, better. So it's a huge part of having a successful project. You have to have trust. You have to earn their trust. And you also have to trust them. And you have to be able to let them kind of make decisions and move things along as well.

Tom: 20:47 Tip number three: pick a process, any process. So you must have a process. If you don't have a process- and a process can be many things, which we'll touch on in a second- but you will have what I call chaos. And I've managed projects that are chaos, where everybody's just doing whatever they want. It's complete and utter chaos. And everybody just wants the project to end. And when you have no process in place, steps to follow, steps that everybody can get around, it naturally just inherently causes chaos.

Tom: 21:24 But a process could be your own homegrown thing that you create. You sit in a room, you say, okay, how am I going to run this? How do I want people to organize things? And you create your own steps or process or however you want the project to run. That's absolutely fine.

Tom: 21:38 It could be a methodology, like we've talked about in previous episodes. Or as simple as a visual workflow, which we promote a lot here at Rindle, promote with our customers. But just like steps and things you follow as a team to prevent chaos.

Brian: 21:54 And honestly, we really do promote this a lot. Once you pick a process, go through the entire process that you decide to go with, at least for this project. Because it's very important that you see it through. Most of these processes that are formal processes have a reasoning behind why they do certain things.

Brian: 22:21 So if you do choose a formal process, do it the entire project. And if you do your own process, especially if you don't have real formal training, which you don't because you're an accidental project manager, you should probably base it off some more formal methodology. I don't know if you would agree with that.

Tom: 22:46 Yeah. I would just add to that, saying always, as we commonly say, keep it simple. So you don't want to go out and find the most complicated methodology out there, for example, for your first project and your first PM experience and have that overhead on you immediately.

Tom: 23:05 Not only are you new to the position, you're new to the role, you're new to the team, you're new to project management in general, but now you've stacked on a complicated project management methodology that you have to figure out.

Tom: 23:18 So that's we promote heavily on the visual workflow, because it's simple. It's very simple for you to follow. It's very much about setting up your work visually, and a simple process for your team to follow. But yeah, I would say, even if you go on your own, follow a guideline but keep it as simple as possible. Don't get locked up in complicated methodologies and things like that.

Tom: 23:38 But you should have some process. And I outlined here- as simple as thinking of it in chunks, or more of a waterfall thing, where- okay, I don't know what I'm doing. I don't have a methodology. I'm not sure what my process is going to be. You can just break it out to be like, okay. Well, I'm going to organize my project. I'm going to organize my resources, understand those things. I'm going to plan and schedule my project. Talk about budget, if

Brian: 24:00 ... that's needed. Capture any costs involved with the project if needed. I'm going to execute this project in some way, fashion, or form. And then any changes that happen, I'm going to record them and make sure they're documented. Right?

Tom: 24:11 Sure.

Brian: 24:12 Simple thinking like that will get you probably through a project, right? So, worst case scenario, even if you just think about have a plan for your project management, right? Okay, I'm not ready for methodology, or I'm not going to put a official process in place yet, but I am going to at least outline, hey, what are the things I need to do to have success here, and make sure I kind of at least have this guide to get me through.

Tom: 24:33 Yeah, I think that's a really great guide that you just suggested. We should ... We'll definitely put that in the show notes so people can see that percent.

Brian: 24:42 Yeah, definitely.

Tom: 24:45 Awesome. Tip number four, focus on the customer's needs. We've talked about this before in previous episodes, really focus on whatever the end goal is, especially if it's customer-based. You want to deliver what your customer really needs, not what you think they need.

Tom: 25:06 Yeah, you want to really listen to what your customer's saying, and what their keys to success is. We talk about this in a lot of detail in episode 19 and 20. It's our documentation episode, which is odd, but when you're documenting the client's needs, you want to know what are they deciding ... What needs to be delivered in order for this project to be successful? You have to relate to your clients in that regard, because if you don't do that, your project probably won't go too smoothly.

Brian: 25:45 Again, it's like to what you said, not only focusing on what the client really needs compared to what you think they need, but also focusing on what they think they need may not be 100% accurate, right?

Brian: 26:02 Sometimes the client thinks that, hey, I need X, Y, and Z, but you're like, "Actually, you're focusing on the feature, not the problem," or something like that, right? So, it's really listening to your customer to figure out, well, are they really understanding what they really need, or do I need to help interpret this for them? But also, to the same respect, like you said, not letting your own opinion flood in too much, where you're ultimately delivering something different than the client wants, right? So, yeah, it is a perfect balance, because you won't have a sensible project just because you won't meet the client's needs.

Tom: 26:31 Cool.

Brian: 26:32 Tip number five is keep your promises. This goes for clients, stakeholders, and your internal team, and everything, in my opinion, but I think the key to this is not to overpromise, which we discussed before as well. But it prevents not keeping your promise in the future, right? So, the biggest, I think, promise breakers are when you say, "Yes, yes, yes," to everything, you kind of promise the world, and you will eventually break those promises. You lose trust from your team internally. You lose trust from your clients and external stakeholders.

Brian: 27:03 So, the cold hard truth is the best route, which I mentioned before. Just kind of be honest, be open. You'll definitely gain more respect that route, either from your manager, your bosses, your team, your client, whoever it might be, and it will prevent you from being the guy or girl who says, "Whatever they say is not true, because they never meet their promises. They never meet their goals. They never deliver."

Tom: 27:25 Yeah.

Brian: 27:27 It's just a really hard spot to be in when you do that.

Tom: 27:29 Sure, yeah, definitely under promise, over deliver. That's just a rule. I mean, if you're doing client work for paying clients, this might cause you to unfortunately lose some bids early on, right, because someone else might be promising the world. But at the end of the day, those clients might have to come back to you because that other team, most likely, is not going to be able to deliver what they're promising.

Tom: 27:57 The first time they do give you a shot, and you deliver more than what they wanted, you just won them over, probably. And they're probably going to keep coming back to you, because they know that they're going to get more than they asked for, or more than what was promised them in the timeline, or in the period of time where the project was taking place.

Brian: 28:24 Yeah. Another good example too that I've based myself, but sometimes it happens from a non-client perspective, right? It might be internally. You might get this project or this role kind of put on your lap, saying, "Okay. We need you to kind of take responsibility for these projects," or, "this project." And then the first thing they say is, "By tomorrow, can you let me know how long it's going to take?" Right? And you're like, "Oh, wait a minute," right?

Brian: 28:46 But your first answer's usually, "Yeah, absolutely. I'm totally taking responsibility. I'll get it done." But you've just made a promise that you're probably going to break already, right, because you don't even know what this project is yet. You haven't digested it, and now you have to make a whole project schedule, which, if you are truly an accidental PM, that's going to be a challenge in itself.

Brian: 29:04 Even things like that, just be smart about it. You say, "You know what? Actually, let me have time to digest this, or review my resource or review the requirements that you gave me, and what you want me to do, and then I'll get back to you with when I'll have a timeline." Right? It's about managing expectations, and not always saying, "Yes," or, "No." Maybe it's just, "Hey, actually, I need more time for this. I'll deliver it here." And nine times out of 10, that's going to be absolutely fine, right, whether it's a client or your boss or whoever it might be, just to not ... I used to do this. I swear I used to do this all the time, when I'd always be like, "Yes," or, "No." Right?

Brian: 29:35 I learned very quickly that I always pretty much 99% of the time gave an answer of, "Well, before I do that, let me first review." Or, "Let me do this and then I'll do this." And it always bought me the time I needed to digest and properly understand what was going on and give the best result.

Tom: 29:53 Yeah. I think a lot of people, especially new to this sort of thing ... I mean, I feel like I'm even guilty of it still to this day and to some extent. They just want to answer very binary, like "Yes," or, "No," answers to questions like that, when it doesn't have to be so "Yes," or, "No." The other person's human, right, and they're actually ... at the end of the day, they want good results more than they want just someone that's yessing them to death. So, it's better off that you kind of give them a, "Yeah, I can let you know by tomorrow when I will let you know," more or less, right? Like, "Give me the night to digest this and then let me talk with the team and we'll try to map out a timeline." Right?

Tom: 30:45 That way, the next day, you're not delivering ... having to deliver the timeline. You're just letting them know that by the next day, you'll have a plan in place, right, for when they will get that timeline.

Brian: 30:55 Yeah. Sometimes, you'll get push back, right? If it is your boss, and they have some other kind of requirement or deadline they're trying to meet, sometimes you'll be like, "Hey, you know what? I'll give that to you by end of week," and they might come back to you and say, "Actually, I need it by Thursday because of this reason." Like, "Okay, let's compromise and work that out," right?

Tom: 31:10 Sure.

Brian: 31:10 But it's not always, again, not "Yes," or, "No," and they're always ... There might be push back. There might be adjustments that need to be made, but again, we're in a professional environment. This is a normal business practice where you're kind of figuring out what the needs are on all sides and coming up with a solution that's going to meet everybody's needs, not just one need, right?

Brian: 31:29 I think that's the key is always just kind of presenting what your need is, and then if you get push back, okay, how can we adjust? How can we compromise?

Tom: 31:36 Awesome. Let's talk about some tips from taking action.

Brian: 31:40 Yeah. For me, I think the biggest tip out of here, if you're an accidental PM, and this is happening to you, project management is about common sense in many cases for me. I think that that's, a lot of times, why accidental PMs happen is because you have common sense. You're good at maybe just naturally leading, organizing your thoughts, taking initiative, and just making common sense decisions. And a lot of times, be like, "Okay, well, you know, Brian could probably do it." Right? And it kind of falls on your plate, which I think is a good thing.

Brian: 32:15 When in doubt, definitely lean on your common sense, and I would say focus on creating business value, whether it's for a client, or even for our case, we have our customers for our product. Whatever you're doing, there's somebody on the other side receiving whatever the result is, right? And if you focus on that value, you will have success.

Tom: 32:37 Well, I think that about wraps us up for the day. If you have a question for us, you can call into our voicemail number at 860-577-2293, or you could email it to us at workflow@rindle.com.

Tom: 32:50 Our theme music is an excerpt from Thunder Rock by MagikStudio. Use under creative comments. Subscribe to us on iTunes by searching for Workflow and visit rindle.com/workflow-podcast for a full transcript of each episode. Thanks for listening, and we'll see you next time.

Tom: 33:09 (singing)