 Welcome to Intuitive Project Management, the third day of Dublin, but obviously the second day of sessions. Is everyone having a good experience so far? Awesome. That's great to hear. So this is my first time in Ireland, and I'm actually of Irish descent. I saw this lovely rainbow on Sunday, the land of rainbows, so I wanted to share it with you all and bring it into the space. I'm really excited to be here, and excited that you guys are all here joining me. So just to kick off with a little bit of introductions, I'm Molly Burns. This is actually from my first day in Ireland, when I'm a Game of Thrones tour, I don't know if anyone's fans of the show, but I got to hold the sword. I'm an account director with Phase 2. I've been working in Drupal for about eight years. I started off working in a small non-profit editing content, and I also was one of the content managers and producers for one of the first large international Drupal sites, was the Drupal platform at Sony Music. So I sort of launched over 300 sites and saw all these really weird edge cases and all the things. So that was kind of my trial into Drupal, and since working at Phase 2, I've managed a lot of different projects on Drupal 7, and I've also been working with Drupal 8 for the last two years, and I worked on one of the first builds before Drupal 8 was even out for Memorial Suncattering. So there's been a lot of great learnings, and my role really is on the people side of the projects, working between people and communicating between people. So this is kind of what I'm gonna bring tier to today to share with you all just some tips at things that I've learned and how I kind of frame things when coming from the intuitive side of the house, how I bring that into the project work that I do. And I'm also a crystal collector, and I did bring some crystal balls as advertised in my session description to keep the vibes going. So you guys are in the Drupal community, so you sort of understand what I just went through. But when I meet people out in the real world and we get in the conversation of, so what do you do? My first answer is, oh, I do internet. And for a big percentage of people, that's actually a completely fine answer, and they just keep moving. They're like, oh, okay, cool, yeah, internet, great. Like, you do internet, we get it. And this is from a great show called The IT Crowd, I don't know if you guys have seen it, but this is the internet in a box, and everyone believed this in the business meeting that she brought the box to, so it was pretty funny. But yeah. But then some people who maybe know a little bit more about how the internet works and who works on it will ask me one of these two questions, and they usually follow each other, so they'll say, ah, so you must be a developer. And I'm like, no, I'm not a developer. Oh, oh, designer, you're a designer. And I'm, I'm sorry, I'm like, no, I'm not, neither a developer nor a designer. Which, you know, there's people really, I can understand what that is. So then they're like, they look at me really confused. They're like, so what do you do? And so then I started to get into this conversation, which is I work with the dark matter of the internet. I'm the gel that kind of makes things happen in the background. I'm working between the technology and the people to get a real understanding of what needs to happen to move things forward. So in dark matter, you know, in the galaxy, there's all these, there's like these galaxies, these are the points of light, and then there's sort of all this other like black stuff in between, and no one really knows what it is. It's the majority of the galaxy and it kind of, I mean, we're going to the universe and it holds together all of the light, which are kind of like the website. So I like to say that, you know, I'm in the dark matter using my intuition and kind of seeing all the things to kind of pull together what, what maybe needs to happen in a project or to kind of get things moving, just like the dark matter in the universe. And so, you know, the role that I have and the different jobs like project management and some other requirements specializations are really come out of the shift that we've seen in the internet from static to dynamic. So over the years, we've moved actually from a system of, you know, webmasters, flat HTML files to actually entire systems that are content management systems that have a bunch of different users, a whole bunch of different permissions, and also different integration points between systems. And so, these dynamic systems actually require a lot of coordination to even stand them up to understand what they need to be because people are in there actually using content, manipulating content in a certain way. So, you know, when we're working with these dynamic systems, there's a whole lot more forces that we need to be aware of and a lot of different players that maybe we're not around in the earlier days of the internet. So, moving into intuition, I just kind of want to get our terms defined. So, intuition is all about what you feel instinctively, not necessarily what you're reasoning. And intuition, everyone has intuition. It's like a core part of being human. But oftentimes in the world we live in, reason and logic kind of trumps intuition and people often don't listen to their intuition. And so, one of the things that I've come to in my experience with projects is really getting into a space of respecting and listening to my intuition and then figuring out ways that I can actually apply this in a way that makes sense to other people and can be converted into actionable items and actionable steps to actually move a project forward. And so, you know, this common feeling of a gut feeling, how many people here have had like a gut feeling about a project or a gut feeling, just like show of hands. Yeah, you're just like, I feel like this is, there's an issue here. I feel like that person's not saying all the things they need to say to me or I feel like, ooh, this module, I just feel it's gonna blow up the site when I download it, right? So, these gut feelings that we have, we really need to be conscious about them and listen to them. But, I also love this quote by Robert Heller because the gut feeling is not enough, right? Just having a gut feeling isn't necessarily gonna translate into the action to sort of, you know, get it out of your gut into the real world to sort of start processing what your intuition is telling you. So, we're gonna walk through a few tips for that and also some frameworks that sort of get what's in your gut sort of out. But, I do also wanna caveat which is say that I work a lot with my intuition when I'm managing projects and working with teams and working with clients. I tend to lead from there but I also wanna acknowledge that there are a whole bunch of other key project fundamentals that project managers and technical leads and anyone that's running a project need to be aware of to make a project successful that your intuition alone is not going to be the end all be all for your project success. You need to have an actual plan. You need to go through and make sure your requirements are detailed. It's really good to have a project methodology or you're working with Agile or you're working with WaterFold. Are you using Gantt charts? All of these things are like really, really important to get things organized and aligned. And then of course having the metrics and reporting to kind of circle back and be reporting on the velocity of the developers looking at the features that you're developing. And then lastly, which does actually key into the intuitive piece is how you're actually managing risk and how you're templatizing that for effective management. So all of these things, intuition is just another tool in the toolbox to bring to the table with a full stack of like best practices in project management. And although I'm not gonna be touching on this stuff anymore, I'm happy to talk about it after with anyone who wants like more actionable project management tips. I'm also able to talk about that. So definitely find me after if you wanna talk about that. So one of the key places where I apply intuition like during the course of a project that I find are like the sort of like seminal points is sort of when we're in the beginning of the project and we're defining objectives and goals. And then sort of as we head into the project there tends to be a lot of assumptions about things. So we're gonna kind of talk about how to work through assumptions. And then lastly how we kind of tie all that together and we work through risks. So this is gonna be the framework that we're gonna walk through. So starting with objectives. The key thing about any internet digital project is really understanding this critical point in my opinion is that every project is starting from a place of someone trying to describe to someone else something that literally doesn't exist. And in that actual process there's a lot of things to suss out and our intuitions can be really helpful for asking the right questions to get us to a point where we're transmuting this confusion of you know this invisible thing is what I'm imagining. And then on the other side we have the team going well this invisible thing is what we're able to build with a system that you decided on using which in this case is probably gonna be Drupal. So this transmutation of confusion and to clarity around the objectives of the project of like why we're doing the project as well as what we're building. But the why we're doing the project actually is really critical to make sure everyone's really clear on that. Because if you don't have clear goals that everyone is aware of you're going to get very tripped up when you start trying to apply scope and you start having different things coming into play as far as what people wanna be building. So I'm gonna tell a little bit of story about this airport. And so the first time I gave this intuitive project management talk was actually in Spanish in 2013 in Ecuador in a very small town called Loja Ecuador for the Drupal Latino Summit. And they asked me to come talk about project management and so I was like okay well I'm talking about two different project management. But I was a little nervous to be traveling internationally and I was looking up this small town in Ecuador, Loja, it's actually a city but a small city in Ecuador and I noticed that the airport was under construction. I could fly into one or two airports and I kept watching the flights. The airport might be opening, we're not sure when it's opening so I'm looking at the flights. So finally the airport opens like two weeks before I get there so I'm like okay great the airport's open. I fly into the airport and this is what I see when I actually get there. There's rebar, there's construction, there's dirt pits, there's rocks, there's all this stuff. But the key thing is that my plane was able to land at the airport. There was air traffic control, there was, and I don't have a picture of it unfortunately, but there was this beautiful asphalt runway that was like brand new gorgeous runway. So the airport like top goal here was like we wanna be able to land planes here people. Like that is what we're doing. That is the goal. Do we need the coffee bar? Do we need the taxi stand? Oh actually the taxis were outside. So the taxis were there but there just wasn't like a stand for them. They were just kind of standing outside this rebar gate. So we were able to actually achieve the goal of landing the plane. And so sometimes when we're in the course of the project people might get caught up with where's our snack bar? We need the snack bar on this website but it's like dialing back to the beginning of the conversation. Well, when we talked about your goals, the top goal was being able to land the plane and being able to open this airport. And so I like to call this MVP airport and whenever I'm thinking about goals, whenever I'm kind of planning that out this is a really good thing to bring in your head of like are we going down a rabbit hole in the snack bar or is this about landing the plane? So these goals that we're gonna be defining in the beginning of the project and really like sussing out through a lot of questions are actually gonna help us through the rest of the project because all of the things we're doing we wanna be able to trace back to one of those goals that we have in the project. So we wanna say like, okay, yeah, that feature that you've just defined that new feature that's actually more of a snack bar feature. So do we really want to deprioritize this boring asphalt grinding task for the developers and then maybe the client will say, that's a really good point. We do need to grind that asphalt. It's not quite as like fun for me as like picking out the things that are gonna go in the snack bar but at least we know that we're gonna be able to land that plane. And so sort of once we have our goals defined these kind of roll into this iron triangle. I don't know if you guys, everyone is familiar with this and sort of a very common project management framing. We've got this triangle and we've got scope, timeline costs and sort of we got the quality, the deliverable in the center. And the common caveat is, pick two of these things that you want and the other one is gonna have to shift. But if anyone's had a conversation about this with a client, they want everything. Everything is important. It's like, no, no, we want the scope, we want it on time and we only have this amount of money to get it done. So one of the things that I like to do is, number one, I like to make the guests for myself using my intuition, using what I know about what I think their priorities are and then reflect that back to them and ask them, what about this? And then really, really making it clear that although they want everything, they're going to have to give me an absolute priority, scope, timeline cost. And when people are in the position of actually having to make a one, two, three list, like they make that list pretty quickly whether like we can't get any more money, like cost or they're like, yeah, like we don't really need to launch it in April. Like we could launch it in June and we'd be okay. So, having this conversation and then also using what you know about the client or about the project to really get an understanding of this is going to be critical when you start to make those decisions and you start to have those negotiations during the project. But in reality, I like to think of the projects as a little more of a pyramid, right? This is an organic pyramid. It's like a crystal device that's transmits energy and we can talk about that after someone's interested in organic. But I thought it was a great photo because it kind of shows the complexity of like, you know, we've got the triangle here but there's all this other stuff, like the nuances, the interpersonal dynamics, the external factors. I once had a project that was derailed by a hurricane. Okay, like that was not in the iron triangle. That's like in this project pyramid that's like full of all of this kind of whirling things and all these different nuances. So really like kind of thinking of your project as not just your project from this neat little triangle but kind of like really like sinking into the fact that there's a whole lot of other things that are happening here. And the more you're aligned and the more you're connected to what those things are, the more you're going to be able to drive your project to success. So I wanna talk a little bit about when goals are conflicting because this can often happen with projects. And I had actually a couple of recent examples in the last year where a client was saying well we want this site and we need to buy this X-Date. And then in one of the examples I actually found out that they didn't actually, well they wanted a site but they also had all these platform requirements that they sort of gave to us like a week in. And so I actually had to suss out through conversations, well do you want the site or do you wanna platform? Because if you wanna site buy X-Date, you're not gonna get a ton of reusable code because we're pushing to make this date or pushing to get this site up. If you wanna platform, you're not gonna actually get anything like to launch or to see on the internet because the first couple of months of building a platform are really laying the groundwork. And so it took me a couple of weeks actually to really suss this out and to get all the information so that I could have the conversation with the client and say, okay, you've got these two conflicting goals and we have one team and we know that there's a timeline. So I need to know where we're gonna go here. What do you wanna prioritize? Do you want us to focus on the platform or do you want us to do the site? And that was a conversation that had we not had that conversation at the time, we probably would have gotten to the end of the project and everyone would have been really unhappy but because we had this conversation, everyone was on the same page, the team started building the platform, the communication was there and we all knew what we were driving towards. So really making sure that the goals are clear but that the goals are not in conflict with each other. And that is a critical nuance and I think one that can often happen in projects. So making sure that the goals are actually aligned with each other. So I wanna move into assumptions and this is really gonna be the meat because assumptions sort of happen at all times in a project. And I often find that what I'm doing as a project manager, as an account director, I'm really the person that's like seeing the assumptions that are happening and then trying to find ways to clarify them so that we can move forward. And sometimes these assumptions actually present themselves as problems, right? A client will say, I'm confused about this, this is not doing what it's supposed to do and the developer says, I don't have this requirement, I'm waiting for two weeks for this and it's like, how do we get together? How do we knock through what these assumptions, what these blockers are and what people are actually thinking is happening on one side, maybe it's not happening on the other side. So I'm gonna talk through a little bit more about the framework of assumptions in a bit but I just sort of wanted to highlight since we're here and we're talking about Drupal. There's been some common Drupal assumptions that's come over the years or with CMSs in general and I'm not gonna talk through each of them but the key one that I wanted to talk about here because I think it's a really common one is this idea of we have a CMS so that we can now control everything we see on the screen with the CMS. So anyone that's worked with Drupal has been aware of the theme layer and the look and feel of the site. Often the look and feel of the site is actually being controlled by a whole other set of files in the theme layer that doesn't necessarily allow someone with CMS access to go in there and change color, change an image. Now certainly you can build the site so that there are certain images that can be updated in the CMS but if there's any core pieces of the site that live in the theme, they're actually not part of the CMS. And so a lot of times what I spent the beginning of projects doing if we're gonna be using Drupal is really just giving you a quick primer of what to expect with what we're doing and how Drupal actually comes up. So it's basically like, hey, there's a theme layer, there's gonna be a CMS, we're gonna have a database, really just going through the big picture so people really understand what actually they're getting with the system that we're building it with because sometimes these assumptions are actually assumptions about what people are expecting the CMS to be and it's not necessarily something that we're gonna be changing in the course of a project. So they're like, yeah, we wanna be able to update that. Well, okay, if we go ahead and make that updateable by you, that's going to cost X, Y, and Z of your budgets really not gonna be useful actually with all the other things you wanna accomplish. So sort of getting these common Drupal assumptions out of the way in the beginning really, really goes a long way in sort of setting you up to have less assumptions down the road. And then also like listening for what people, what people say they think is happening and then just like immediately catching that and being like, oh, actually, interesting, you said that but that's actually not how Drupal works, it works like this. Do you have any more questions about that? So that's kind of a way of like unpacking these assumptions upfront. So over the years, I have kind of developed this framework of all the like assumptions or problems that come through and there's sort of like four parts of the framework that things fall into. So the first one is like the internet level assumptions. Like people are literally making assumptions about how the internet works. And these are very common because again, we go back to that box of the internet, not everyone knows how the internet works. I mean, it's like sort of is this magical invisible thing that just came on the scene like, under 50 years ago and has transformed our planet but it's still a bit of a magical mystery to many people including me, certain parts of it. I'm not saying I'm an internet expert but I happen to know more about it than the average person. So a really common one is this issue of the fonts and how they work in older browsers. So I don't know if anyone's ever had this where you're working on a project and you're like, wow, like the colors, the CSS and the fonts look completely different in IE than it does in Chrome. And a lot of times this can be an issue, especially with larger companies who might not, they might all have run some old Microsoft thing running and they don't update it because it's gonna like, they had to coordinate with the IT teams. So it's like half the company is running some old version of IE and even though we've looked at the analytics and their website analytics are like, okay, 3% of the people are actually seeing this issue, they're like, well, our whole company sees it. It's a really big deal. You need to fix it. And then just kind of being like walking them through and be like, okay, well, you know, this is actually an internet level issue. Like we can't make the old browsers read modern CSS and we don't wanna write old CSS because it's not gonna be good for the majority of your users that are on modern browsers. So really having these conversations and having them from a place of real compassion for like, yeah, like this internet stuff is like kind of like weird and magical and let's really unpack like how it works. DNS propagation is another fun one. If you've ever launched a site and you didn't lower your TTL file, you might have had an issue of, well, you said the site is live but I'm not seeing it over here. So yeah, the internet level problems are fun. Then we started to move down the stack, move down the stack into the system level problems. So the sort of concept of like, we talked a little bit about the common Drupal project assumptions before. So this is sort of where things like, Drupal specific things come in. Like that's not how the system works. And like a really common one is related to caching. So people expect that they're going to enter content into a page. They're gonna press save and then they're gonna see the content live on the internet in a minute. And that really is a very, very common assumption and problem that comes up that really requires like getting ahead of it in advance. So a lot of times if I assume that someone's like not really familiar with how caching works and I'll actually like say this in advance, I'll be like, hey, so like, yeah, you're gonna be updating your content. And then it's like 10 minutes later, 15 minutes later, everyone's gonna see it. And that's just how it goes with this system. I mean, I know you've seen Facebook and that's got the instant update. So it's possible on the internet, but we're not gonna be completing that here with the system framework that we have. And additional system level problems or system level assumptions kind of come through. How are the modules working? What's happening with the patches? What's going on with the distributions? There's all these different processes that we as Drupal people kind of assume and we know, but the sometimes the people that we're working with and building projects for aren't actually aware of. So just being aware of when you hear these coming through and what type of issue it is and say, oh, that's a system level issue. Like here's how we can kind of clarify and converse to get to a place of understanding around it. Next is a business level problem or business level assumptions. So this has to do with sort of like things that are happening in a business or at an organization that then get reflected in the digital properties. So as businesses are growing and becoming more and more digital, the websites or web integration systems are often so core to actually getting things done in the business. So we have a chain of people that need to approve the content and we only find out last minute that someone does this weird, they stamp a piece of paper in real time, like on a floor, that could actually be automated so easily in a system like this. So sometimes business level assumptions are actually my favorite ones because we actually get to say, oh yeah, we can build you that in a day and it'll change your organization completely. And it's gonna make someone's job a lot easier. So these ones are actually can be really fun and can be really, really rewarding. And so another one kind of here is just sort of on the other side of things, like organizing people's content and organizing their taxonomy and telling them what their taxonomy is. A lot of times there's this, there's this like, oh, we have a website. So our business problems are solved and it's like, no, no, no, you still have to have that conversation interdepartmentally to figure out the list of your taxonomy. And we can't do that for you. We can make you space where you can put those taxonomy items in, but that's a business problem that you guys are going to need to solve and guess what? You should solve it a month, two months before we have to build this feature because we need to know if we need three taxonomy box, like three taxonomy items, like subcategories or if we only need two. So sort of tying in what those business assumptions are to have dependencies on what you need to build is also pretty critical. And lastly, we have the people, the people problems or the people assumptions. And at the end of the day, we're all people and we work with other people. Yes, we have these computer interfaces between us, but really what we're dealing with is different personalities. And a lot of times like we have in a project, this homepage example comes up so much, but people are really, really attached to this concept of getting their content on the homepage. And so really asking those questions, well, why do you need your content on the homepage? Oh, well, I need to send it to this person so they can see it that it's there. Well, could we create you a special landing page that you send to them that you're able to update? Oh, I didn't know that was possible. Yeah, that's great. So just really like trying to hear where people are at and where they're coming up with their assumptions and then having the compassion to sort of try and solution with them, but kind of taking everyone at face value. There are different communication styles. There's different personal life events. Oftentimes with a team member, I'll notice some things happening and I'll say like, hey, are you okay? What's going on? And I'll be like, yeah, someone in my family is having an illness and I'm taking care of them. And so really just being aware of the people around you and what's happening in their lives and being in tune with that and then kind of making allowances for what you need to adapt to in your project plan to sort of accommodate and work with what people are going through and what's happening in their lives is important. And yeah, power struggles is also a fun one. I often find coming into organizations, I see the power struggles between people and being an outsider, being a consultant, often find that sometimes my role is saying things that they can't say and sometimes I'll even say to someone, hey, like I'm noticing this dynamic, is this a real dynamic? And they'll be like, yeah, that's totally a real dynamic. I'm like, would it be helpful if I said this? And they're like, yes, that'd be very helpful. So really like using your position as a change maker in organization as bringing in these digital projects is how can you actually help move things forward and unblock things if there is a political issue or a personality issue that can be causing, I mean, mostly if it's causing an issue and the project is when I'll step in, I'm not just gonna start getting into the mix of everyone's office politics for no reason, but if it's something that's impacting the project, really understanding what that is and then figuring out, okay, what is the people mechanism that I can do to help move it forward? And yeah, I mean, just to sort of like there's all types of people and we're all working together. So really like also not forgetting the site users is a big one. A lot of times when we're building projects, we're building for, sometimes people get away from like the people in the internet that are using the site. And so, working with some UX experts at phase two, they're always really good about being like, well, the actual user is not going to understand that. We need to consider this. So really kind of having this people focus, compassion, empathy and using your intuition to figure out what needs to happen for all the different people that are gonna be interacting with your system, both long-term, when it's out in the wild, but also your project and your client relationship to actually get it done. And I really do wanna continue on with the people thing. I mean, we're all just like beautiful, magical, sacred beings and we all have a lot of the same things at our core, right? Like love, we feel lost, we wanna be accepted, we're communal species, we like being in community. We're here at DrupalCon, it's great community. We wanna belong, we wanna be accepted. There's also like a lot of fear, there's fear of failure. This project is gonna mean everything. I might lose my job and people really do get into this fear space. And so really like just recognizing that and then kind of intuitively tuning in to like what that means for like, how everyone's gonna be aligning in the project and sometimes there's even like this fear of success, right? Like certain people it's like they're afraid to even succeed. And so if you kind of pick up on something with someone, whether it be a team member or a client that they're feeling fearful, really just trying to like envision like, well, what are they afraid of? And how can we assuage that fear as a big one? I have a lot of times like, we're just really afraid of this launch because we had a really bad launch two years ago and this is what happened and all of these things happen. And so really understanding where people are coming from and what their experiences are and saying, okay, so like I hear that you had a bad launch, I hear all these things happen, well, guess what? In this launch, we're gonna do a load test and we're all gonna watch the load test and we're all gonna see what happens. And we're also gonna do some validation on a couple of these integrations. We're gonna do some pre-tests. We're gonna make sure that the information is going where it needs to go. And so just making sometimes allowances and extra plans if you do have kind of this some fear about a project launch can really go a long way and making it smoother for everyone. As far as the people kind of understanding people and working with people, I'm a big fan of sort of these kind of personality tests and personality and people kind of analysis tools. I think they're really helpful. At phase two, a bunch of us, we all did these Myers-Briggs, the 16personalities.com. And it was super interesting just to see what everyone's personalities were and how to work with people. We had the really analyst-y, logic people who it's like they need to have all the data before they make decisions. And then there's people like me who are just like going from my gut and I already have the decision and I already know what needs to be done. But when I work with people that are the data people and the analysis people, I need to say, okay, I know that this person is a data analysis person. So I need to take a step back and I need to be patient while they collect all the data to really feel comfortable about the same decision that I've already instinctually made. And really having that understanding of who you're working with can go a long way into being intuitive about what they need in a communication to actually move it forward and not have a clash. I'm also really into human design, which is a little more kind of out there but it's interesting. And the website definitely needs a redesign so if anyone's looking to pitch that that could be a good one because the website's terrible. And then this dope one is really good. It's really simple. One of my clients actually sent this one to me because they had did it at their team and everyone is a bird. There's four types of birds and everyone in the team gets assigned a bird. And so that was kind of a fun, light way of like being like, oh, you're a peacock and you're an owl and you're an eagle and there's sort of different ways of how those types work with each other. So definitely recommend doing this. And then just like in the day to day really asking people questions. Like when you're on a conference call in the beginning of the conference call and you're waiting for people to come on, like there's this dead space and it's one of my biggest pet peeves. Just like sitting on this conference call, like waiting to start the meeting. That's a perfect time to like just have some small talk. Talking about the weather is fine. It brings people together. You can learn about people. How is your weekend? Are you traveling? What are you doing? Like what else are you into? You know, all of this is really important and considering the whole person is gonna make a big difference for when you're trying to build something with them. So yeah, communication 100% like critical, key, important. This is the core of kind of all of the sort of people work and the assumptions that we've walked through in this section. It's like the crux of everything. So, you know, don't forget that in the digital world, we're really all just talking to people really at the end of the day. I mean, granted there's times where we're heads down and we're writing code and we're looking at data but people are really the driving force between behind all the things that we're doing. And an important thing in communication is listening. I don't know if anyone's ever had this experience or been this person, I have both. But this concept of like, are you actually listening or are you waiting to talk, right? Are you waiting to talk or are you really listening? Are you really getting in tune with what the person is saying? And this is something that I've definitely learned over the years and it's been invaluable for me to actually understand people and be more effective in doing my job. But I've kind of taken it a little bit further. I don't know if anyone's heard of like this concept of active listening where you're really like, okay, you're actively listening and there's different skills you can do. You nod your head and there's active listening. I've sort of taken it in my own experience one step further and I like to practice what's called energetic listening. And so energetic listening definitely has some of the same things as active listening where I like doing the tip is if it's like a really, I don't do this all the time, but if it's sort of like a critical meeting and you're really trying to understand, sometimes I'll actually repeat what the person is saying in my head so that I can really, really internalize it while they're saying it, almost like a meditation. And then it's always important, eye contact, nodding, like just like that simple like, okay, I'm listening, like it's not disingenuous. It's just, it's a way of acknowledging that you're tuned in to what someone is saying. So yeah, nodding, eye contact, but I also tend to do like a focused direction. So I'll even turn my body when someone is talking or I'll look at them and move my body in their direction. So I'm not just nodding and looking at my phone or nodding or like nodding over here. It's like really tuning in energetically to what the person is putting out there and also in looking at their body language as well. And this last one is really key. It's listening for what's not said, listening for what is not mentioned, what is being left out, what is being avoided? And that can actually be even more telling and even more valuable to the situation than what's being said. And so sometimes that's another thing that I like look into. Wow, that wasn't mentioned in the meeting. I wonder why, you know? And then even having a smaller meeting and asking the person, hey, is there a reason why you didn't mention this in the meeting? I know we were having some issues with the server, like why don't we bring it up in the meeting? You know, and then to find out, oh, well, you know, I didn't want to hurt this person's feelings because I know they were really stressed about it and I didn't want to bring it up in front of the group. So, I mean, there's all sorts of different reasons why someone doesn't necessarily say something. And so kind of being aware of that and intuitively digging in to what's missing can really be the key to unlocking some critical things. So I want to talk a little bit about the advanced, the advanced practices of energetic listening. So this is a little hard to do over the phone, but you can definitely do it in person. It's all about shifting body language. So, you know, if you're like this in a meeting and you're like, you know, it's not really very open friendly. So sometimes if I see people that have a closed body position, I'll actually be more open in my body position when I'm interacting with them. So I'm trying to like bring that open body position into the room and people actually do mirror. There is this concept in human interaction where people will mirror each other and mimic each other. So if my body language is open and I'm nodding and I'm engaged, then that's gonna potentially have a ripple effect to the people around me. Another thing that can be really important is that sometimes in a big meeting, there can be this concept of like, you know who needs to say the next thing or you know, you see someone that's like, they wanna say something, but maybe they're too shy and they kinda make a move. And so a lot of times when I'm in a meeting and I'm sort of like, you know, facilitating the meeting, I'll actually just turn to that person, even though someone else is talking, maybe it's someone that talked too much in the meeting is still talking. So I'll actually turn to the person that I think should be talking and just like look at them with an open body position and turn to them and kinda nod at them. And that can kind of often move people into the space of like, oh, I feel seen and I feel like someone is tuning in to my energy of wanting to say something, but I haven't actually said anything yet. So, you know, these are some little advanced practices, but it definitely does work. You know, you can also just ask them to say something as well, but sort of teeing that up with the body language really does go a long way. So, kind of like moving from the listening and talking about, you know, when you turn to the person, these are some, I call it the metaverse meeting tips. These are some meeting tips that I actually got when I worked my first corporate job at Sony Music as mentioning to you guys one of our creative executives. He was like really dynamic guy, really great in pitch meetings, you know, just really understood how to be in meetings with people. And these were his three rules that he sort of, I mean, I modified them a little bit, but this concept of like, does it need to be said right now, right? Like, is this something that has to be said at the moment? And for me, with really tuning into my intuition, if I'm supposed to say something, my heart actually starts beating. I don't know if anyone else has that experience, but I know some people like, will get like a heartbeat, like, oh, I gotta say it, like it's really here, I need to say it. And so I'll really tune in and be like, oh, okay, I guess I have to say it, you know, that this needs to be said. And then the second question is, if it needs to be said, and this can be hard, especially if you're someone that's a big talker, is like, do I need to be the one to say it? And for me, working in tech projects, being kind of the non-technical, non-developer person, I often find that I have an instinct or I have a knowledge about something or I know the system and I've worked with Drupal and I've seen this happen a million times and I know that this decision is not right for the caching layer or this type of server is gonna be wrong, but it doesn't always come out that, you know, effective coming from me, especially if I'm talking to like the head of IT for a big company or a big organization. So if I know something needs to be said, but I'm not the one to say it, I'll often like talk with a co-worker and I'll say, hey, in this meeting, it would be really great if you said this. And so they're teed up, they know they need to say it, they have, we've strategized before the meeting about what needs to be said. And so that understanding of like the delivery and who needs to say it is really, really important. And then the last question sort of that I asked you of is if someone else needs to say it, like how do I facilitate them to say it? So if it's like my team member, like I just said, I'm sending them a little ping and the message like, hey, can you say this, I can't say it, but I really want you to say it. But if it's a client, oftentimes it were in a meeting and I see someone quiet in the corner who I know is in charge of this thing, I'll often ask them a leading question so that they will say the thing that needs to be said. Like if I know that they have no one on staff to support a Drupal instance, I'll often ask them, oh, is it, who's gonna be supporting the Drupal instance? And then they'll say, oh, we're still starting that out or oh, we don't have anyone on staff for that. And then the whole room has heard that and everyone knows where we're at. So that kind of teeing those things conversations to come up is really, really critical. So moving into the last sort of gathering our intuition and how do we make it actionable, risks and risk management is like my favorite part of this project management because it actually allows you to take all of these intuitive things that you've pulled out of all the different parts of your project from when you've defined the goals up front to when you've seen what assumptions have been coming to light during your project. You actually get to put them in a really data-ish way that's going to let them be more actionable tools for moving your project forward. And there are tons of unknowns when you're in a project and sometimes you're not knowing something is actually something that you're going to want to put on your risk list and you're going to want to bring up like, you know what, we don't actually know this or we don't know what's happening over here. And not being afraid to acknowledge this is a big part of what sometimes keeps people up at night. It's like, oh, if we don't know this and we're afraid to say it, it's releasing that and making it seen and putting light on it is a really, really critical part of making it more known. So the thing about risk management, as I said, it's my favorite thing to do in projects because it helps me bring the intuition to the table a little bit more, is that if you do it when everything is on fire, it's not gonna go as well as if you just do it as part of your project. So it's like, if you're like, let's mitigate all the risks when everything is blowing up, not everyone's gonna be in the space to be really confident and collaborative about risk mitigation. But if you bring a risk management approach throughout your project, you're actually teeing up a safe space for people to talk about the unknowns, to talk about the fears, to talk about those prickly political issues that might throw a wrench in the project, to talk about the, hey, we're building this on a system, this has never been technically done before, like how are we mitigating that, what are we doing? So using risk management log and having regular meetings to talk about risk has been a great approach that I've used in a lot of my projects and a lot of our teams have been really successful on using as well. I don't know if everyone can see here, but we've got this, all the data people, we got a spreadsheet, that's very necessary. And the spreadsheet has different categories. You've got a status, is this risk open? Do we get to close this risk? If we've successfully mitigated a risk, we can close it down. And we also have a person responsible for it and then we have a mitigation plan. And what we'll do is we'll actually share this with this risk log with all of our team as well as all of our clients. And this is just like a collaborative process that we're like, okay, well, in our risk meeting last week, we talked about this, let's review this risk, oh, we mitigated it, great, new risk, okay, let's put that on the list. And so we're able to actually have these conversations like way, way earlier in like a really like safe space that's not stressful, that's not, we're up against the fire and we're like talking about the fact that we're unsure of who's gonna be maintaining the servers like when the server's down. Like that's not the time to be having that conversation. If we've already had the conversation, then if the server goes down, then we're like, okay, well, we know it's this person and if it's not this person, we know it's this person. So we know they're on it or I had a project example that I wanted to bring in here. So we launched this website and then we had a rollback plan, if the website, if anything happened and we had mitigated it, we had planned, we did all this risk mitigation. And so we launched the site and this site went down and what we found out was after the fact is there was this random spider that had been attached to the site that spidered every single piece of content in like two minutes that they had not known about. And so this is like, go back, this is like the hurricane. Like who knew that someone had like a spy spider for all of their content that was hitting the site and when we launched a new version, all the URLs were new and it caused the site to crash down. But we had mitigated if that would happen what the plan was way before. So when the site went down, we were like, oh, that's not good, but so and so is already doing the rollback and blah, blah, blah. And then in an hour, we were all on a meeting and we're like, what happened, like what's going on and everyone was trying to figure out and then we found the spider and then we were able to move forward and replan the launch. So that like having had this actually happen several times, I really started to see the value of like making sure that we have these plans we have these plans in place. So with risk management, there's kind of a little bit of caveat which is that we often have risks that we can't necessarily say the whole risk or the whole thing, or at least I can't at one time. Sometimes the risks have to kind of unfold, right? So I sort of feel like there's this concept of like a long game risk that like if there is something that I feel like someone needs to be aware of or take action on but they're not necessarily ready to admit that it's a risk, I have to kind of put a strategy in place of like what's the first part of the risk that I'm raising so that in two weeks, we're going to really be able to be mitigating it honestly. So one example has to do with them be working on a big project and you know, client will say, you know, we've got this new developer and we're gonna bring them on and they're gonna do a bunch of work to help us get this deadline. And so, you know, my response to this often is like, great, like it could go really well. The developer could hit it out of the park and really engage or maybe I don't know their skillset, right, I don't know this person, so maybe they're actually not gonna be able to get as much done as possible. So oftentimes what I'll say is like, okay, you know, why don't we do an evaluation in one week and look at the tickets and the code that they've done and make sure that they're on target. And so then when we get to that week in the evaluation, you know, hopefully it's successful, but if it's not successful at that time, then we can have the conversation of like, ooh, looks like we're not gonna make our launch date because X, Y, and Z happened and this plan of bringing on this other person hasn't actually panned out. So kind of like, you know, preparing how you're going to stage the risk conversation, especially if it's around like going back to those political issues, some of those political issues can be thorny if you're working in a big organization. So you wanna be really careful about how you discuss some things and how you stage the risks and finally you'll get that like aha moment where it'll like all kind of come into place and everyone will be like, ah, yes, like and this is how we will mitigate the risk, but it doesn't always turn out like that. So just kind of be aware of this long game strategy. So lastly, I wanted to sort of, you know, do a little bit of exercise with you guys if you guys are open to it about getting in touch with your own intuition and so sort of what I think comes up for me with this is the importance of just listening to yourself and listening to what's in your body and what's in your thoughts and what's kind of coming up for you. And so we're here at DrupalCon. I know people have probably traveled far to be here and so what I sort of wanted to do is maybe like kind of everyone to kind of go internally and really start to think through, you know, what are your goals for being here? What is your intuition telling you you need to do in the next couple of days? What do you wanna learn? Who do you wanna talk to? What do you wanna bring back with you from this experience? And I know that, you know, get some like introverts in the room probably. So this is just like a personal activity. You don't have to talk to anyone about it and it's only gonna be for two minutes. So hopefully you guys will be game. So I just wanted to like kind of bring you guys into a little bit of a different space than the conference space. And this is my drum, it's the hummingbird drum and just wanted to kind of like offer everyone to maybe close your eyes if you're open to that and I'm just gonna walk you through a little bit of, you know, a little bit of a meditation to kind of get connected to where you're thinking and where you're at. So if you could close your eyes and everyone just kind of like do a big deep breath in like really inhale and exhale, like feel into your body and let's do another. All right, so I'm gonna do a little bit of drumming and during the drumming, if you could just kind of keep that inhaling and exhaling and really get connected to what your intuition is telling you and where it's drawing you and what you wanna get out of this day while you're here. So I'm gonna start and it's just gonna be really a silent meditation and keep those breath, this slow breath going. Getting in touch with your intuition and for joining me in intuitive project management. There's an evaluation link over here on the site and there are also some fabulous sprints that are happening on Friday. So please check them out and engage with all of the fabulous people in the Drupal community who are here and yeah, thank you all for coming. And if anyone has questions, I'm around. So come up and work out as I pack up.