Episode 1 : We Are Chaos Junkies
Published in
16 min readMay 3, 2018
Show Notes
Work and projects can be chaotic, and that’s not always a bad thing. In kicking off a topic that can truly drag projects down, Brett shares a story about how a project was going really well…until it wasn’t. That sparks a conversation about not only how to manage through chaos, but to embrace it. Greg talks about his experience working with teams and finding what works best when you’ve got to wade through team chaos — because working as a team can be tough to figure out, and chaos doesn’t only come from client work.
So take a break from your current chaotic episode, and listen to this episode of Sprints & Milestones to find better ways to solve problems and stay chill when things get nuts.
Links Mentioned in This Episode
Order the book — Sprints & Milestones comes from the pages of Project Management for Humans. Get your copy now at Rosenfeld Media, Amazon, or Barnes & Noble.
Transcript: Episode 1 — We Are Chaos Junkies
Announcer: Welcome to Sprint and Milestones, a podcast where Brett Harned and Greg Storey share war stories, tips, tactics, and anecdotes on navigating the sometimes rough waters of getting digital projects done. If you're leading projects and want some help and reassurance that you're doing the right things, you've downloaded the right podcast. Enjoy the show. Brett Harned: This episode is sponsored by Teamgantt, a company I've been lucky enough to collaborate with for sometime now. Teamgantt is an online project management platform that helps you to create intuitive and beautiful project plans. For more information and a free account, visit Teamgantt.com. On with the show.
Greg Storey: So on our first episode we introduced the topic of digital project management and how it applies to everyone. This week we're jumping into these principles starting with we are chaos junkies. And I think, Brett, you've got one of the perfect stories to kinda kick this off.
Brett: Yeah. So I think in my career as a project manager I've worked on tons of projects and many of them were chaotic. And I don't necessarily always think of chaos as being a bad thing, because I do consider myself to be a kind of a chaos junkie because I know that I can jump in and solve problems, and if I can't fix them myself I enjoy going to people and having conversations and having them help me solve problems.
So I'm gonna talk a little bit about a project that I was working on that actually was going really well until all of a sudden, it just wasn't. And I think a lot of people can relate to this. So I had a client, I would call them less than tech savvy, so that was always a challenge right? Because they were people who didn't really understand the work that we were doing, which meant that they didn't understand why it took so long. They could sometimes not keep up with presentations. And I actually like that kind of scenario because I can take the opportunity to educate a client on process and deliverables, and break down how things work. So that part of the project, and that sort of little slice of chaos was okay by me.
And as we're swimming along toward the end of the project, something that really felt almost unfathomable happened. The lead developer, really the only developer on the project, got really sick. And there was obviously nothing that you can do about that, like human nature, right? But it meant that he was gonna be out of work for an extended period of time with no contact. So essentially all of the files were left in one place, created by one person. And of course the client had a deadline, so just somebody dropping your only developer from the project is a little chaotic.
Greg: Well and they probably also don't understand how difficult it is to come from behind and look at another developers work and just simply pick that up and stay on track, right?
Brett: Absolutely. I think a lot of clients who are not tech savvy, or not part of a process, which is many clients, they don't realize that throwing another resource at a project isn't necessarily the solution to things. So that added to that, you can't just plug and play. There's onboarding to be done when somebody new has to come into a project because not every developer works the same way.
So of course we had other developers on staff but there were no back ups because everyone else was booked on priority work, and that's the way that it goes when you're working with a small team. So it was up to me to find a freelancer, and the work was being done in Drupal, which was kind of new to me at the time. And I wasn't really sure what I looking for. Which was difficult. So I did have to pull in some people to help me to figure out how I was gonna find the right person, how I was gonna get this person on boarded when we did find them, and also how I was gonna make sure that the person who was a complete unknown to me or anyone in my company, how they were gonna actually do the work and if they were gonna be accountable for it. So to me that was a little scary. Like that was the chaos, right? Missing the person who I was really relying on, who was really good at this job, and then replacing that with a complete unknown entity.
So I had to organize the chaos. So some of the things that I did there were first I obviously had to let the clients know what had happened and I was doing everything in my power to make sure that there were no issues. Obviously they weren't happy but they kind of had to comply. There was nothing else that we could do. There was no choice but for them to trust me and the rest of the team that we would fill that spot. So in order to make them feel comfortable with the chaos, I set up daily check ins in the morning and at night. So I would check in with the team, figure out where tasks were so we could move things, and I could actually report back to the client so that they knew that we were doing the work.
I found one developer on the team to take some time to review the work done, and to help on board the new developer because development is not my strong suit, I would never tell someone that I can actually review code and know that something is quality. And that's important. Knowing what you can and cannot vouch for in a situation like this, and calling in the people who can help even at a minimal level is important.
We set up an internal ticketing system for the developer to log questions without exposing those questions to the client. Because again, I wanted to clients to know we had it, that it wasn't gonna be a problem for them. So keeping some of that kind of like detailed confusion behind the curtain was important to me. And so then I paid much closer attention to tickets. I organized thoughts, made every task really as clear as it could be for this new person on the team. And I had questions coming in to me from the clients, from the new developer, from my boss about how things were going. So I knew that I had to put extra effort in to make sure that everyone was comfortable and that I was kind of like smoothing out the waves or the giant tidal wave of confusion that was coming at me. And I know it could easily go off the rails, and that if it did go off the rails it would pretty much be my fault because I was the one who was really trying to organize and everything, and kind of lead everyone to a goal.
So I did everything I could to make the transition seamless, not only for our clients, but for the new freelancer to know that I had his back too. Thinking that if he sees that I trust him, he'll trust me and actually will be accountable for the work.
In the end we launched three days late. But I still considered that a win given the giant, gaping hole in the project that took a few days to fill. The dev came back three weeks after the project launched and was able to revisit the code to make some changes that were sort of up to his standards. So when he came back from his leave, everything was pretty much done, but he wanted to make sure that his sort of seal of approval was on it. Which I felt like was a really nice way on his part, to kind of wrap everything up and insure that that time where the team went through a ton of change, and confusion, and chaos, he came back to smooth it over. And that worked out really well.
Greg: Well that's just a little chaos for you, right?
Brett: Just a little.
Greg: I mean, given that you were able to launch just three days late given everything that had to be set up. I've been in a similar situation before and that's not easy.
My college mentor, and I guy I took a lot of classes with in advertising he would always say a client won't remember it's late as long as it's good. And I don't know, I don't know about you, but I think to some degree that's true, but I feel like there are people out there they want you to stick to that schedule no matter what. So I'm kind of curious, having been in a similar situation, these clients in particular, were they empathetic at all to the situation? How did they respond to all this?
Brett: Yeah. So they didn't respond the way that I think I personally would respond, which would be oh my gosh is he okay? Is everything going to be all right? It was more about like, "Okay, well that happened so how are we gonna beat the deadline?" So we didn't spend a lot of time on the I hope so and so is all right kind of conversation, we focused more on talking about the solution to filling the gap and how we were gonna be focused on resolving the issue, proceeding with the work, and making sure that we launched on time or as close to on time as possible.
So I was really clear about this is gonna create a delay for us, I'm really sorry. There's nothing that we could really do about it. I mean honestly, there's nothing that you can do when it comes down to someone's health, and if you're not a giant company with endless people to kind of go to. So really the pressure was kind of like on me and the team to make sure that they understood that we were honestly doing everything that we could to make them happy.
And I agree with you, I think a lot of times people will remember the recovery more than the problem. Which I like to think is what happened in this situation. They saw that everything was organized, we changed our approach for a new person coming on to the team, we did a lot of check ins, communication was almost double time. And it worked out. Yeah, we were a couple of days late, but that really truly was unavoidable.
Would I have like for them to be a little bit more empathetic? Yeah, but at the same time I understand business, and I understand that everyone has someone to answer to and a deadline is a deadline. So we just did what we could.
Greg: And that's I think some of what compounds a situation like that too is given the size of the client, and I feel like when you work in a small shop or a small department even, and you're trying to serve a much larger entity. Whether that's a company and organization, or even a larger department. I feel like there's a lot more pressure to stick to very rigorous schedule. Like they had a very rigid process, and any kind of deviation from that, my experience anyway, just gets met with a lot stress and anxiety, and being told that's not possible, we are gonna hit this deadline or heads will roll.
Brett: Right.
Greg: Yeah, so it just seems, I don't understand, but it seems to me it's impossible to try to follow a rigid process. I shouldn't say try to follow a rigid process, but to stick to a rigid process even when things come up.
Brett: Yeah, I think that's the biggest thing that people don't account for when it comes to project management. You know if a lot of people think project management is following a process, which to a degree we do follow a process, but no project goes from point A to point B all the way to point Z perfectly. There's always gonna be some kind of chaotic event that happens. Whether it's someone leaving the project, or the goals changing on the project, or whatever it might be. There are a number of things that can happen and so it's good to have an idea of process and things that you can or should do. But imposing some kind of very strict structure, to me, is counter productive. I'd much rather identify points where process can change, or where you could talk about points where process can change. To be a little bit more pro active about that change, rather than not knowing what to do when this kind of chaotic event happens.I guess what I'm saying is no matter what you do you have to be flexible or adaptable. It's not that we can't follow a book, it's just that we don't need to. Because, in digital specifically, we're expected to adapt as clients require it. Working in client services is a big part of that, but change occurs pretty often so we just have to adapt to it.And I do feel like there's a lot to be said about understanding practices and processes, and then breaking them to make new ones. Or adapting them. The process I set up for check ins works on smaller projects, and people actually like that, checking in more often because they know what to expect in terms of daily communication. And that's what worked well in the scenario that I described.But yeah, I think really what all of this is meant to say is that a good digital project manager is gonna keep trying to get a situation right by trying new approaches to everything from communications to deliverables and process. Until it feels like they finally got it right and it fits. I mean there's some education that you can do particularly with the type of client that I talked about to get them to understand the process and how things are gonna work. But it might not always stick, so you have to change course along the way. So we're comfortable, and I'm comfortable as a digital PM being in the thick of that chaos. And like I said before, sometimes we like it because we know there isn't an issue we can't solve because we're chaos junkies.
Greg: Right. Well so to that point, there's two things that since you and I have worked together that I've seen. I've either put into practice or one of my design directors has. And the first is in my time at IBM running incubator projects, we learned after a season or two, cohort or two, that it was inevitable that the teams, no matter what, there was gonna be a pivot. And it was a change. And we called it a pivot because it wasn't necessarily like the work was gonna stop and we had to start all over again, it was just the fact that the direction we were going in had to take a slight left or right turn.So we ended up just telling the designers before these cohorts started that it was gonna happen. And it wasn't so much a scare tactic it was more of just trying to set expectations, not only with the designers, but also their stakeholders that they were working with. And chaos ensued, it always does. And even when you make that change, it's probably the most chaotic because there's so many factors that you've gotta address to make sure that the team's still delivering on time. It's just that what they're delivering may change.And to that point in my current role, I've got a number of design directors that work for me, work with me. And one of them met with all of her stakeholders, got them in a room, and they went through some exercises to kind of define what chaos could like like, and kinda what they're working agreement is with one another. So that it's almost like an emergency response system. So that when a problem arises, and that could be anything from not getting approval for user research, or at least not in time, right? And a lot of it has to do with time. And an understanding and agreement that if one thing slips here, it has potentially that butterfly effect, right?
Brett: Right.
Greg: And we'll see how well it mitigates risk. To your point, it's not gonna take away from the chaos, but I think given the example that you just shared with the client and the teammate who got sick, I think having some of those tools can help, I don't know, maybe draw out some empathy for one. And kind of get those folks to relax a bit, to understand that no ones gonna use that as an example, or sorry as an excuse of not delivering on time, right?
Brett: Right.
Greg: That they should be able to trust that you're still gonna get the job done and that you know how to navigate all that chaos that's erupting all around.
Brett: Right. Yeah, I'm kinda sitting here thinking in that moment of chaos, maybe the most important thing for a lead or maybe all team members to think about is what can I do in this situation to make sure that everyone is comfortable with how we're changing? And for me it was double down on communications, make sure that people are really clear on their expectations of what they're to deliver, and follow through on making sure that they're actually following through on that. Follow through as a communicator, I guess is what I'm saying.I think to me that's the most important thing is that's where empathy comes in on the PM side. Is how can I make everyone else comfortable? On the client side you never know what's gonna come at you. So if you can just be a good communicator and understand goals and challenges on the client side, I think you'll be able to smooth things over as much as possible. So just be open to conversations and being honest about change and chaos, and letting them know that you've got this, you're gonna lead the team to the end no matter what. That's gonna make everyone comfortable.
Greg: So, speaking of chaos, and the stories that you just shared, how do you know what kind of chaos junkie are you? How does chaos appeal to you? How is it you feed off of it?
Brett: So I think at first you have to know that chaos is always gonna be there, like it's creeping around every corner, right? So know what kind of chaos you can function in. Going in you know where you can rally support in places where things are not your strength. So for me in that situation it was around Drupal, and development, and code, and making sure that somebody could actually come in and help me lead that. So I think it's about knowing your strengths, but also keeping in mind those goals and what other people are thinking. I don't think you can say I'm good at this kind of chaos versus that kind of chaos because it's always tricky and it's never clear cut, right? But just knowing that you can kind of take a minute to regroup, think about it, pull people in, and solve a problem is really important.
Greg: So speaking of strengths, have you heard of StrengthsFinders?
Brett: Through you I have, but I've never taken the test.
Greg: Okay. Well just know it takes 30 to 40 minutes, it looks like it's gonna take 10, but it takes a while. Yeah, the output of that I think is for anybody who's kind of even asking themselves, what kind of chaos might I be able to handle? And how do my personality traits end up being either a strength or a maybe a factor in to how I'm able to manage chaos? The test can go a long way in I think helping you understand what type of chaos junkie that you are.
Brett: Yeah, I'm gonna check that out.
Greg: Yeah, you talked about communication which is perfect because in our next episode, we're gonna talk about how project managers have to be multilingual communicators, which is the next principle.
Brett: That's right I'm looking forward to that one. It's all about how we speak different languages, not necessarily me speaking Spanish and English, but me speaking about legal, and IT, and design, and all of these topics that really come into play as a PM. You kind of have to be able to speak a little bit of every language so that you can kind of keep things moving.
Greg: Yep.
Brett: But I think that wraps it for this episode. Thanks for joining us. If you wanna learn more about the principles we're talking about on the first season of the podcast, check out my new book, Project Management for Humans, it's out now. Chapter two is all about principles over process and you can learn more about being a great communicator in that chapter. Thank you.
Greg: Thanks.Announcer: You've sprinted to the end of this episode. Milestone complete. Thank you for listening. If you're looking for more resources on digital project management, check out Project Management for Humans, by Brett Harned, which is available on amazon.com or through Rosenfeld Media. And of course, don't forget to subscribe on iTunes. And check out our show notes and more at sprintsandmilestones.com.
Subscribe to the Show
Download and listen to the Sprints & Milestones podcast on Apple iTunes, Google Play, Stitcher. And thanks for listening!
