 Okay so in this session we're here to talk about becoming a technical project manager. Now we've got a nice full room today so if you do have any questions we're going to have a spot at the end where we can do some Q&A but before then if you do have anything you can go on to Twitter and just type the question and put the hashtag Drupal TPM. Jason he's our scrum master today so he's going to be shouting out questions so feel free to be engaged during this. We're also going to have be taking collaborative notes that are going up. There are going to be a lot of resources and different tools that we're talking about. Don't worry too much about writing every single one of them down because we're going to give you a full list with like notes and links and everything else that you're going to need. All right so my name is Jessie Fisher. I work in kind of technical client services at Pampion. A lot of my work is around kind of onboarding projects and getting people set up. I've been with Drupal since 2011 and I moved in from a pretty non-tactical role into doing some pretty kind of like highly technical stuff. Cool and my name's Ann Stefanieg. I currently own and run a Drupal shop called Canopy Studios and I've been working in Drupal since 2007 back in the days of 4.6 and Flexi Note. It's dark dark time but here we are today and I came from a very non-technical place and I get teased because I sometimes say I'm non-technical but I tend to do most of the scopes of work and a lot of sales proposals so here we are. Jessie and I are here to share our tips and tricks and help everybody learn more about technical project management. Cool so we're going to start off with the definition of a technical project manager and originally I wanted to title this talk superhero cat herding. Project management is usually called herding cats because you have a lot of different people and you have to get them all in the right place. When you add in the technical aspect of that that's when it gets to the level of being superhero cat herding so you're going to see a lot of cats on all of our slides today and that's kind of what we're going to be referencing. So starting off with what a technical or a project manager at that level does you're really just responsible for the planning and the execution and the monitoring and the control and kind of the closure of a project. There are four basic aspects to go into this and we're going to be referencing a lot of these aspects in our talk today. The first one is being a bridge. You are going to be the bridge between kind of the the client's problem and what the ultimate solution to that problem is and also kind of bridging in between your client and your developers. You're also going to be gatekeeping a lot. You need to protect your developers protect their time protect kind of the scope of the project and everything that's going on and you're going to be doing a lot of education for the client telling them what the process is and kind of like what is and isn't possible in this world and then the even trickier thing that you have to learn how to do is to kind of see ahead in the future and anticipate issues before they bubble up into an explosion and a bad situation and you want to do all this so in the end you can deliver a project that everybody really feels good about. So when I talk about bridging there are kind of two lions that you're going to be bridging in between and these two lions are very different creatures with very very different needs. So the first line we have this is your client. This is your business partner. The needs that this client have clients need meetings. They need a lot of updates about progress about blockers and other issues. You're going to spend a lot of the time on the phone with them and doing Google Hangouts and chats and things like that. They also need really well-defined expectations and they need to be educated about this process so that they have proper expectations and they don't feel like they're surprised or that they've been kind of lied to in any way and they also need to have some of their big ambitions and dreams brought down into reality and the way to do this and what they really really need is kind of firm empathy. Don't be afraid to tell a client no. You just need to do it in kind of a kind and understanding way. So your developer lion has very different needs from the client lion. They need to be heads down to get the work done. They don't need a lot of distractions around them. They also need somebody who can speak their language so that they feel like you really I mean that you understand them. They need a lot of help being able to communicate kind of what the technical problem is or what what issues are going on and communicating out to the client and also communicating kind of those red flags that can come up. You need to feed them and you need to feed them with properly defined tasks. You don't want to go to a developer and just say hey build me a website. See you in a month. You want to be able to break it down into bite-sized tasks. You can continually feed them to get the project to the endpoint. And finally they need to be fed also with lots of words of encouragement both in failure and also in successes. Okay so we're going to talk a little bit now about the definition of a technical project manager and how that differs a little bit from an actual project manager. So let me see if I can do this. So TPM is one of those competent folks who grew up through the technical ranks and really took his or her place through wit skill and the ability to communicate clearly to non-technical audiences. These people clearly understand the full stack and know how to walk the walk and most often talk the talk. Oh made that backwards. They can talk the talk and most often walk the walk. These people are the really key defining factor between a technical project manager and a project manager is that they can communicate effectively with a non-technical audience. They're usually very able to estimate and troubleshoot because they have been there and done that. Now remember you don't have to be a developer to be a good technical project manager but sure does give you a step in the right direction. So every project has time, money and features as the three pillars and only one gets to win. If you have a very busy project and the timelines are the most important thing you may have to sacrifice some features or maybe the client has to pay overtime to get it done. But either way there's only one pillar that wins. The difference on the perspective from a technical project manager is that you weren't hyper focused on features and you somehow you magically have to make all of these features work within a certain number of budget or a certain amount of time. So that's really the focus of a technical project manager is they're trying to figure out the actual solution to get the job done within the constraints that they're being forced to play with. Let's talk a little bit about day to day of a technical project manager. And a lot of this does sound a lot the same as a project manager but one of the big things is that you're going to write a lot of reports. And if you're coming from a developer it means that really writing things down in real time thinking about how to document it and that could be really challenging. But it's something that's going to become your best friend. Essentially you want to become a really good firefighter and you want to actually take away the kindling in matches from your clients and even your developers and good documentation is a great place to start. So you're going to send emails like a lot of emails and then you're going to phone a lot of people and you're going to slack people and you're going to text people and you're going to send some more emails. Another thing a technical project manager does is they help prioritize issues. And that goes as identifying the problem that's potentially at the root of several problems. So as a technical project manager you're in charge of employing strategies for risk mitigation. And this is on the technical level. And I got to say the most common thing that a technical project manager does that's different from a project manager is they pull at least one person per day out of a tempting rabbit hole otherwise known as an unrelated technical problem. There are kind of two tracks to getting into technical project management that we're going to outline today. The first one is going to be talking about a project manager to technical project manager and then also from going from a dev to a TPM. If you're starting from ground zero and you want to get into this world like the next few slides you're just going to have to learn kind of all of it. So as a project manager to get to a technical project manager you have to become technical. This can be a little bit overwhelming when you start to get into this world. And I think it's really better to think about it in these three major categories when you're starting out. One you need to understand the structure of Drupal. You need to understand the lingo that people are using. If you check out Drupal.org there's a glossary that's on there. Read it understand it. Get the language and the words that people are using. And you also want to kind of deconstruct a finished project. It's kind of like doing reverse engineering when you were a kid and you wanted to be like how does this phone work. You get a screwdriver. You open it up and then get yelled out by your parents. You also want to kind of understand the stack for Drupal basics. You know you have a server. You have the operating system that's on that and then you have the application. Of course it's far far far more complicated than that. But at a really base level that's kind of how you want to start conceptualizing it. Now once you understand the structure you want to understand the tools to manipulate that structure. How do you get in? How do you build these things? How do you take something that's already been built and start to manipulate it further? What are the tools that you'll be using? And don't worry we're going to give you a little list of all this. Outside of that once it's built it's been manipulated. You know all this stuff. How do you investigate what a problem is? Because the set of tools that you use for testing and kind of investigating and debugging are different than the tools that you're going to really be using to build. There are a lot of Drupal training resources that are out there. And again on the notes we're going to give you a huge old big list. And you're also a Drupal comp so there are a few other resources here as well. It's really hard to just spin up a site if you're a non-technical person looking to be a technical person. So like Jesse said you know go and connect with your community. But taking something apart is so much easier to understand because it also gives you a foundation to which you can ask questions with. Yeah when I started getting into this people were telling me like people who knew this really well were like well it's easy you just go in and you like spin up like you know lamp stack and you just start building a site. But when you come at it from that angle it can be really overwhelming because you don't know what modules you need to be picking out. Like there are just so many options you don't even know where to begin. So what I recommend doing is to actually see if you can get somebody here and and we'll try to get you like a repository of something that you could pull down because if you can look at a finished project and you can look at something that's already been built out instead of just a skeleton bare bones Drupal site you can start to get a sense of all the different components that can be in there and then you could take it and also start breaking a little bit to see what happens when you change like a small line of code here. Play around with it and start investigating it that way. Another thing you should get really familiar with are things like Stack Exchange, Stack Overflow, reading through Drupal.org. If you have a problem somebody else has already had that problem as well most likely. So when you go in here like you can go read and see what issues people are having in different areas and just like be curious check out threads that have been on like views and different kinds of integrations and stuff like that. And it's kind of a pro tip about Stack Exchange and Stack Overflow. The top voted answer is not always the best answer. Sometimes it's just been sitting there for a while and it's just gathered a bunch of upvotes on it and then that thread has kind of been abandoned and nobody's looking at it and somebody else comes along that actually has a much better answer and you don't see it. So learn to just like read down and you know use your your own perspective and kind of analyze it see what their arguments are and then maybe try and play around with what their answer is. Another thing is learning the fine art of Boolean searching. I work kind of more in the technical support space and people love to make this joke of haha let me Google that for you. It's surprisingly hard to be able to use a search engine effectively beyond just like Boolean search operators will give you a little link for the search operators that you can specifically use with Google to be able to kind of drill down because you're trying to find like this tiny little answer that's needle in a digital haystack. And also don't be afraid to kind of play around with what your search terms are. You can try one tack of like you know this piece of the error code and like not including Drupal in there but if you include the word Drupal in there you make it a very different set of answers. So always be refining your search terms and learn how to be able to use search operators to kind of narrow it down and keep going through the pages until you start to see the results you're looking for. Just on that note we I worked with a very senior developer who was one of my inspirations. His name is Nick Lewis. He's super awesome. And when I asked how did you how did you learn all this. He's like I learned how to use Google. So step one. Learn to Google. And the last piece in here like outside of having an internet connection and being able to like read all these forums that are in here. Go to meetups. Smart people love talking about what they're passionate about. If you show up and you ask questions like don't be afraid to say so what is this PHP thing like what is JavaScript. Just start asking them questions and they'll usually be really happy to give you answers possibly more answers than you thought you were going to get out of that question. So once you've done your research start to get into hands on learning. This stuff is going to be a lot easier if you are a project manager already at a company. Start getting into support like go back read the support tickets you'll start to get a sense and this will help you build up your sense of being able to anticipate. You can look at the history of what's in there the problems that have come up and then kind of the resolutions and the answers that are in there. And don't be afraid to start offering yourself up and be like I will take those low level tickets because you can always ask somebody on your team for a little bit of help and they'll be really happy and thankful that you came in to take some of the work that's coming in. Also creating documentation. Nobody likes creating documentation. So if you come in and just ask someone at your company who's technical and say hey you know I know we don't have a piece of documentation on like this aspect of DNS. Can you write me an outline and if they can just write you a small outline you can start working on it and use those things like stack exchange stack overflow searching to if you don't know what a term is just look it up. And you can start to write a draft for it and then pass it on to them and then you know get their edits and their feedback and everything. And this is really going to help you one feel comfortable being an authority and talking about this stuff to clients. And then also really you know learning it and learning all these components and pieces. If your company has emergency on call get on that. Volunteer yourself to go work communications. 2 a.m. emergency alert is a pretty lonely place to be when you're all by yourself. And having somebody there to be able to run communications is really really helpful. And you get to watch in real time as like a website or something is going down. Somebody is going in debugging figuring out what the problem is and then offering a solution to that problem. And it's going to teach you kind of like what can go wrong where these fires can come up and again going to teach you the technical aspects and how to anticipate. And the big thing of this is take notes ask questions and like take on as many tiny tasks as you can and especially take on the tasks that you don't think are going to be overwhelming but you're slightly uncomfortable and unprepared to take on because those are the moments where you're going to have to push yourself to really learn and really figure out what's going on. And just to augment on that I know with some of our project managers that are keen to become more technical we get them to start doing the QA which is quality assurance or user acceptance testing to the more technical tickets and the developer will actually take the time and write very clear acceptance criteria which is part of our process but then it helps the project manager go through step by step. And sometimes you have to open up Firebug and actually look at CSS and just starting to repetitively look at CSS or whatever the structure is starts to you get more familiar and you kind of know what to start looking for. Yeah, exactly. So build confidence, build your knowledge at the same time. Don't be afraid to kind of jump into this stuff. So on the other side of this, if you want to go from being a developer to a technical project manager, you know the tech part. There's kind of a different host of skills that you're going to have to start learning if you've never done project management before. The first one of these is there's going to be a really big shift in what your workday looks like. You need to stop thinking about the code that will solve the problem and you need to start thinking about the person who knows the code that will solve the problem. So stop thinking about how and start thinking about what. You need to keep a catalog in your head of this person is really good at the front end. Like this person knows, you know, how to set up these really awesome like views and give them the tasks accordingly to what needs to be done. So delegate. You've got to learn to start delegating instead of being tempted to get in there and be like, I know how to do this. I can do this in five minutes and fix it. Give it to a developer. It may take them 15 minutes to do it, but they'll get faster and faster at it. So always delegate, get out of the code. But I say that with a caveat. If you get too far out of the code and the technology starts passing you by, that T and TPM is going to start shrinking and your ability to really kind of manage and help your developers and kind of work with them as a team, you start losing the language, you start kind of losing, you lose the plot a little bit about what's going on. So be there to test and sort of always still be able to debug and know what's happening. The other two parts on here around kind of, I'll talk a bit about empathy and interpersonal skills. I think these are always presented as these, you know, hardwired characteristic, like a person is born empathetic and they're just empathetic and they're going to be that way. I really disagree with this. I think this is a characteristic that people can cultivate over time. There was a study that was done a few years ago by these two researchers named Kid and Costano. And they looked at what happened when they had people read these short bits of fiction and kind of tested them on these levels of empathy. And something that they found is being exposed to a lot of fiction writing. So people who are very different from them, it started to shift their perspective and like their ability to be empathetic and their ability to think from another person's perspective. And so this might sound a little bit wonky, but if you want to learn empathy, start reading fiction books, follow blogs like is everyone familiar with humans in New York? Yeah, we have a link to it. Start following things like that. If you're only surrounded by people that look like you, think like you, walk like you, talk like you, your ability to understand the other perspectives that are out there are just going to be limited by sheer exposure. So try to step outside of that if you really want to cultivate these characteristics. The last piece on here is verbal judo. So there is a retired police officer named George Thompson. And he's kind of written the book on verbal judo. And verbal judo is the art of deescalating a violent situation through kind of words and like the way you stand. We have some links up on there as well. He has big long talks that you can read through. And you have to figure, you know, if somebody who was in the NYPD was able to use these tactics to stop someone who was pointing a gun at them when you're on the phone with an angry client, these tactics can probably work just as well. All right. So some really specific challenges that you're going to run into if you're coming from the developer role into a technical project management role. The first thing is you're probably really used to communicating technically all the time. You're not just going to be speaking to other developers, so you need to explain things to clients. The best hack for doing this is to use analogies, like sit down and think about, OK, if I want to explain cookies to a client, how can I use a real world example of something that they're familiar with that's going to help them really conceptualize it and understand it better? Another thing you need to get used to is documenting everything. Every conversation you have, every agreement that goes on, you need to document it. Start building like a secondary brain. And you can do this through emails. You can do it through your project management apps and all this other stuff. But you always want to have that secondary brain kind of running because you can go back and you can reference it. You may think you're going to remember that conversation that you had in another week. Promise me with everything that goes on these projects, you definitely will not. That goes for like one of the tricky things is that as you will become a project manager from being a dev is that you're going to spend a lot of time on the phone and clients will accidentally and maybe not intentionally twist things around. So one of the most skillful things you can do is once you get off the phone, hang up and send a reverse confirmation email like based on our understanding of our conversation, we're going to action this by this timeline and you're responsible for getting me content by that date. And you don't even have to ask for their confirmation to say this is a confirmation of the conversation we had. And if they don't think it's right, they're going to reply right away and say, no, you said Tuesday, not Monday. So having those moments, it's really tricky sometimes to do that. And what has really been hard is just going to go into this but not booking meetings back to back because you need that thinking time right after. Because one thing that's different from being a developer to being a TPM is that you're going to have multiple competing priorities and it's all going to be happening at once. Yep. Usually I like to say you want to keep your calendar where you are about 30, 70 or 40, 60 of meetings to like the followup work that needs to be done. Every half hour meeting you have is going to generate anything from like another 30 minutes of work to two hours of work. And so if you're like, I'm just going to do meetings all day, you're going to be sitting around at about midnight or so still trying to play catch up for everything that you told the clients that you were going to do or you're going to drop the ball on documenting everything and in a month the client's going to be really angry because that call that you had a month ago where you said you do this thing but nobody has any evidence of what was actually said is going to kind of come back around to bite you pretty hard. And the last thing in here, people coaching skills. Something I like to recommend is doing a compliment sandwich. So let's say your developer kind of messed up a little bit. You don't want to just go to them and be like, come on, really? Because they're going to get defensive, rightfully so. The better way to approach it is, hey, you know, you're normally really good at being able to talk to clients and kind of understanding what they need. But they needed it done by Monday and it wasn't finished until Friday. They're a little upset. I know that you can do better. I've seen you do better than this. So next time around, let's keep it on track. And that's an example of really doing you want to give a compliment. The bad news you want to give them and then a compliment after and it'll help them really hear it and be more accepted of it. So compliment sandwiches for everyone. Okay, so being a TPM is hard. Writing code is hard. Managing people is hard. So now we're going to put it all together and now we're going to share some more tips and tricks and best practices in being how you can be a rock star technical project manager. So we have some quick tips here. First off, you're going to live in email land and this is a tip for everybody but it's whether you're a zero inboxer or not, we highly recommend clearing your inbox by end of day before you go to sleep. This makes for a fresher morning and you'll also have a clearer picture on what your priorities are. I think someone's managing the factual. So you also want to understand your priorities and this means like understanding what can be pushed and what can't because some things that can actually be pushed and I know we always try to stick to our regiment and timeline and schedule but the reality is when you have competing things, it's important to know what can actually be moved around. Another thing that we mentioned here is we've said this before but stay close to the code and that means staying up on technology and processes. If you're not working, if you're working as a technical project manager already and you haven't touched D8 maybe it's something it's time to go and play around with. If you fall behind it becomes harder and harder to help your team. One of our TPMs at work brought up when I asked him to look at this was really important in its own your mistakes and own your team's mistakes. If one falls, you all fall and the most important thing about learning from mistakes is the learning part. It's okay to mess up and we all will and clients can totally see through when you're like, well, I don't know what happened, right? So if you can take accountability for the mistake and work together as a team and learn from it, the process around it, you become a stronger manager. Yeah, and this really helps kind of building trust with your end client because they don't understand the technical side of this and what you're doing and they're just giving you a bunch of money and trusting that you are going to deliver on what you said you did even though they don't really have visibility and they may not completely get it. So being able to tell them like, hey, this is what happened. You know, we learned from it. We're not going to do it again. It starts to establish trust. It establishes a sense of like we're kind of all in this together and we're all working together and we're all going to be super honest with each other. And another thing I've noticed, especially around the people that I work with, is the TPMs that really shine is that, again, they have really good abilities to communicate non-technically, but even more so importantly to the team is they're available. They sometimes as a developer, you would usually go dark. Maybe we have a team members that, hey, I don't take meetings or calls on Fridays. I need heads down time. Well, that doesn't happen as a TPM anymore and it's really, really, really important to be available to your team members. You may have team members that are night owls and they work really constructively at night. And even though, yes, we encourage you to turn it off as a TPM, the more connected that you can stay with the project and the team, the closer you can keep an eye on things. And even if you're on Slack late night and you notice your team members online just saying, hey, how's it going? And you would be surprised that sometimes they're really stressed out because they're working on something and just a little friendly hello. They're like, oh man, I'm really cranking on this code but I'm having a problem. Are you around? I'm like, yeah. Taking five or 10 minutes out of your evening to help unblock a developer who's chosen because it's quiet time to think at night makes him or her feel really supported and they can keep the momentum. It will railroad your life a little bit from going into a developer into a TPM role. Your life will change. You will have some lifestyle flexibility around some of the things because it may be quiet at times. Take advantage of the quiet times because it varies in noisy role. Yeah. Okay, a couple more quick tips. This might be not so quick but we've got some more tips here. So another thing is estimating is really hard and it doesn't matter who you are but as a technical PM it'll be put on your shoulders a lot to actually estimate things. So the first thing about estimating is that whether you're close or not to the project you always wanna really involve the key developer or the person who's gonna be executing the solution so they can have buy-in to what that solution is. Now they're probably gonna give you an estimate of time or money or hours. Double, triple, triple it. By Drupal. By Drupal. So you have to take into account that if you are someone that can do this and let's say a task in four hours most likely your development team you think 12 hours, it's crazy. I can't even believe they'll need that time. But the time that it takes to talk to them about the issue, to walk through the solution, to execute, to test, to implement the changes, to send to the client all of a sudden that time gets eaten up. All the windows are gonna open up. The microphones are all gonna explode. It's sucked outside under the street. I do not know what's happening. The monster that might be under the stage is just gonna rise up against us. Okay. So and no one to ask for help. I mean this is a really important one as a non-technical person coming into this role. It's really, it's important to create time in your calendar to actually get some help. And this is also another one is to be humble and curious. It's really important for a non-technical person as you're learning to ask strategic questions and sometimes what you don't know is what you don't know. So it's hard to know what to ask. But being curious and saying, would you take five minutes to help me understand this? And then writing it down like verbatim and then going back and say, based on my understanding, is this what this means? And then because things are so fast in this world, it's often skillful to find some time in your evenings and weekends to review your notes and come up with more thoughtful questions, to do more of that searching and that's really gonna help deepen your understanding. And of course, always know when to turn it off. I think the big thing is that you'll bring the best to your table when you do turn it off. You will have a lot of noise. It's kind of a contradiction to what I just said about being available, but there is an element of actually being able to just take a phone call versus being fully on your computer. And the slide has been completely white. No, it goes, it goes. Okay, so we have three things. We're excited about this slide because I did a lot of quick tips and it wasn't quick at all. So, the first off. I wanna click. Ah, I see what you've done. You got sneaky with it. Oh, I got it. Yeah, so trust your guts. So the first thing is your gut will always be right. Doesn't matter if you're technical or non-technical. If you think your developer is gonna go on my own Friday and we're not gonna meet that deadline for Tuesday, trust your gut and talk to him on Thursday evening and say, my gut's telling me that you might not be available like you think you are tomorrow. Is that actually the case? Because it's okay if you're not and I'll figure it out, but let's talk about it now because it's gonna become really hard on Tuesday morning because Monday's a holiday or whatever you know because your gut is gonna be right. So follow that intuition. Another one is that get to know people. Like really get to know read people and this getting to know reading people comes from reading your developers, reading your clients, reading the other managers. And this is where if you're a distributed team, turn on your video, watch their body language, watch them, watch themselves. Yeah, always like it's best to always try and have like face-to-face meetings with your clients. Being a disembodied voice. I mean, if you just heard our voices over these speakers right now in the room with slides going, it would be a lot less engaging. You'd feel like there were kind of robots going and it might be a little bit creepy. In terms of being able to kind of read people, this goes back to this, I believe, is a skill that you can develop. Start getting into the habit of when you are talking to people, don't just think about the next thing that you're going to say. You know, watch their face, watch their body language. Are they kind of tapping a little bit? Are they kind of pitching up their voice and seeming like they're a bit tense? Watch people when you're out. Like really start cultivating and learning how to read other people's body language. You can get really good at this. Yeah, and just a last thing on that is that often sometimes people drop balls not because they're stressed out at work, but because they're stressed out at home. And there's something going on in their personal life and it's not their responsibility or their obligation to tell you what's happening in their personal life, but they could be potentially dropping a lot of balls. So before coming to any concrete conclusions as to why things are F'd up, talk to them, ask them questions, how you do it and everything. You know, it's just a little bit of a friendly human touch to things. Really helps people, you can relate to them and then help them work through their stuff to say, okay, you need another week, I'll go find another week. You know, and that's your job is to go on your warrior path to get more time or money. And the last thing is about balance. And balance is not life work balance. I'm talking about the balance of understanding how to balance the client's needs with the developer skill set and make that magic happen. And that's a really, really key thing that I learned from Ricky is that what he does all day is magic. Because he's literally figuring out what the client wants, pairing it with the development team and then making it all happen and the client and the developer are both happy. Cool, so a lot of this stuff has been high level of like, how you can learn these things, the things that you need to learn. And we went over a little bit about like day in the life, but we wanna kinda get into the weeds of some of this stuff. What are the specific tasks and like types of work that you're gonna have to do when you're working as a technical project manager? So the first one is creating tasks. Well, you're gonna create documentation, you're gonna help lead your team through all of the things most likely with tasks. And we can task out how to fix this reverb. But first thing is, I mean, it's fairly straightforward. This one? Yeah, this is the solution. Write testing criteria to define done, because that's documentation. It defines in non-technical terms, your non-technical right, your writing skills, and then defining the estimate. And then the most important part of actually sending off a person to do a task is to check in on them. If they have an eight hour task that's gonna take them all day, ask them to do an hour and then come back and check in with you so you can make sure they're going on the right direction. So if we're looking at, we use a lot of user stories because we're trying to blend our clients with our team members and everybody to be on the same page. So we use a lot of user stories for functionality testing. And humans are very into narratives. They can relate and they can understand to user stories. So in addition, not only to user stories, is that again, these narratives or these stories, you're able to relate and you're able to kind of figure out what the client wants and ultimately deliver on that. Yeah, and this goes beyond just like trying to break out tasks by putting them in the framework of like a story. If you are talking to your clients, a good way to preface things is like, okay, tell me the story of your problem. If you're talking to your developer, like tell me the story of the issue that you're having right now. It gives people a good frame to start kind of talking to you about it. All right, so estimation. This is one of those things. There's no calculator that's out there where you can input the task that needs to be done and get an output of hours required because there are so many individual factors that go into it. So the unfortunate thing about it is you just have to fumble your way through it. Sometimes you're gonna have really bad estimations when you start out. If you're a developer, this is gonna be a lot easier for you because you've done it. You know it. You have all the experiences going on in there. If you're not technical and you're getting into this for the first time, you're gonna mess up a lot. It's okay, we forgive you. A way to kind of get around this is every time you have to start estimating out, get your develop, get a technical person involved and ask them like what do you think this is gonna take? And then you can start to learn like the parameters of how long different types of tasks can take. Starting to get a little anxious that it's gonna rise up again. Oh, no? Okay, if I just hold on to this for the rest of the time, I think we're gonna be okay. These might be ungrounded so I'm just gonna grip on to this for dear life. All right, okay. So you're gonna have a tool belt that you need to get together. Beyond having a laptop and an internet connection, there's some really specific tools and like suites of tools that you have to start looking at. The first of these is of course, communication tools. We talked a little bit about the need to be able to be face to face. There are a lot of different ways you can do this. Slack, join me, go to meetings, Skype for business, Zoom, using Google Hangouts. Pick one and standardize it and like just go with that. Another thing you're gonna have to look at are development methodologies. You've probably heard of things like agile and waterfall and we could do an entire session on either or both of those. But the quick way to think about these is any project where there's a lot of lay of the land that's unknown and you're kind of going to be exploring while you're doing development, it needs to be agile because you're gonna have to build kind of the skeleton or the ghost of the minimum viable product. Evaluate it before you keep moving on and this is why you're gonna kind of be reevaluating and reiterating and kind of changing your direction as you're building the project out. If you're doing something that's more like short wear and you have the same kind of modules that you're putting in every time, it's the same basic work and maybe it's just like the content in the field that's a little bit different. It's an iterative process. It can be done over and over again in pretty much the same way. That's gonna be waterfall and it just depends on like what the end product is that you're gonna be building out. And then outside of that, you should be looking at project management kind of tools that are out there. There's so many different types of software and ways to do this from like sticky notes to something like Jira and they exist on kind of the spectrum. On one hand, you have something like Basecamp where it's really pretty and it's got this nice UI which can't change anything around at all. So it's very rigid and you're stuck in what it can do but if you don't wanna have to think about building, like managing the project of getting your project management tools working, then you could go with something like that. On the other end of the spectrum, you have things that are so customizable that you need like a specialist person to be able to build it out so you can start using it. I'm looking at you Jira. And we'll have like kind of a, there's Asana, there's Jira, there's Basecamp, there's Reich, there's like Teamwork, PivotalTrack or Redmine. There's so much out there and my recommendation is to just evaluate them on your own. They usually have free trials, go sign up, see what it looks like, build like a little fakie project in there, try to port things in and see how it feels to you and how it works. The other thing that you need, we've talked a little bit about building out that kind of secondary brain that you're gonna need to have. You may also want to put automated reminders in. When you send an email to your client and you say, I am going to follow up with you on this thing in two weeks. At the moment that you do that, set a reminder for yourself. You can use things like email tracking software, you can use Google Calendar. And what I try to do is to go in there and have a specific block of time in the day where all of my reminders are gonna start flooding in and I just set aside time then and my phone will start ringing and I'm like, okay, two weeks ago I promised this, eight days ago I promised this and on and on and on and you can just start banging it out and your clients will think that you have the most amazing memory on earth. Surprise, you just use automated reminders. And the last little bit in here is testing. We've talked about kind of when you're estimating, you need to put a lot of time in there to be able to test and then to also do revisions. This is, again, kind of a talk in and of itself when we're thinking about what testing looks like. On the left hand side of this V, you can see kind of the process of getting a contract in place, doing all of these, like getting all of these different pieces together and defining them what they are, run through the coding and then going back through and testing all of them. Unit testing is a lot smaller and more at a granular level. Once you've unit tested, you want to look at all of these parts that you know function individually and independently and make sure that they all work kind of together. And then from there, you want to say, all right, well, it worked on my local machine. How does it work on this other server? And then there's also the acceptance testing that's in here. This should be a much, much, much bigger square because it's a really huge category. There are so many different types of, like user acceptance tests that you can do, does it scale, can it handle like really big stress? There's, I can actually put in a really, really good stack overflow article that I found on this where I pulled this image from and it's actually the second answer on there, don't trust the top one. And that can kind of go deeper into it. Like doing testing and all the tools that are out there is a pretty big rabbit hole that we could start going into, but we just kind of wanted to give you a little overview of what that can look like and what you're gonna have to start learning. And then the final thing on here, this job is stressful. You are going to be kind of working as a firefighter. The best laid plans of mice and project managers almost always go awry. So you're gonna have really intense client situations. Adrenaline's gonna get really high, people are gonna get frustrated, you can't. You don't have that luxury in this role. Budget is gonna change, timeline is gonna change, scope is gonna change, whatever you thought you were doing two months ago, it may not be valid anymore in small and in large ways. You also want to employ magic words. And I don't mean this in some cynical way if you need to say these words to make it seem like you care. Like you should care. You should say things like, I understand, I can see this thing. What you're saying, repeating it back and saying, is this what you're telling me? I want to make sure. Like be empathetic, be understanding, and above all, be calm. People can get really hyped up and really frustrated, but in the end of the day, nobody's gonna die, it's just a website. I know that people's like reputations and their careers can feel kind of threatened, but it is just a website. And if you can remain the calm one, because it's really tempting, when somebody is yelling at you, your adrenaline starts to go up too and you're like, oh, yelling now, I'm gonna yell. Try to be the calm one. If you can be calm in this situation, you're gonna be able to herd these cats in a superhero way and make sure everybody stays together and everybody stays calm and even in the tense moments you'll be able to kind of work together on this project. Do you have anything else to add? Oh, I just think again, taking away the kindling in matches prevents you from fighting fires as best as possible, which again, for technical folks, writing good documentation that humans can understand and maybe even physically sign off on to create checklists. Like if you have a pre-launch checklist that goes through all of the things you need to do before you launch, then you can set it and forget it. And the more systems as a technical project manager that you know where people tend to fall in those holes, if you can try to figure out where those holes are and prevent them from even stepping in them, saves yourself a lot of time. Yep, and that is all we have for you now and we are happy to take on questions. Jason, have you been watching the Twitter feed? Okay, well, we can just take your questions now. Hashtag Drupal TPM. As soon as I took it out of this, it stopped humming. Problem solving. Eventually I figured it out. Oh, do we have a, I have a camera up here, if we could, do you wanna hold on to that? So do we have any other questions? Yeah, that's a great thing. It's like, what does success look like? Do you wanna take that one? I don't know if you ever know that you've made it. There's, I mean, you're making money off of it. You feel your ability and your flow to kind of handle tense situations without letting it get to you is one of them. Being able to kind of direct the traffic is where you know you start to make it. But I think all of us have some level of imposter syndrome. I'm constantly sitting there. I'm like, they're gonna figure it out one day. One day they're gonna wake up and the jig is gonna be up. Yeah, and I would say defining what success looks like is finding a good mentor who can help what that path looks like. And there comes a point in time, like I came from a marketing background and what I would do is I would write the scope of work and I would have the developer go in and edit it and not just edit it, but like Google like comment on it so I can see where the changes were. And the thing was, as I realized, I was, my estimates are now more close to accurate. My scope of works are deeper technically. I might not be able to write up exactly everything, but I can write a good paragraph and at least write it in non-technical terms. And what I realized is when other people, why I said, well, I'm not technical, they're like, but you just wrote a scope of work for a 3,000 hour project and I barely edited it. And I was like, oh, right. And you wrote all of the infrastructure. Oh, so okay, all right. And it's actually a place where you have people around you that validate, so. Yeah. It's almost like the more you know, the less you know, right? The more you know, you go, oh my goodness, there's so much more to learn, right? And if you can stay humble and stay curious and to know that the really good technical project manager is one that can anticipate what's gonna happen and help redirect. Yeah, and I think curiosity is also like a really big thing of this. The best developers I have ever seen are the developers that are curious. Something is broken, something is going wrong and they don't panic and go, I did all the steps. It's supposed to work like this stupid computer. They look at it and they say, interesting. And if you can start to develop that kind of attitude and approach to it, remember it is just a website. And it is kind of interesting when things break and start kind of freaking out. I mean, it's not as interesting when you need to have it fixed within 12 hours, but if you can remain curious, it'll help you stay a lot less stressed about it and it's nice to have a curious attitude around the world. Yes, yes. Okay. Yeah, and so this is part of the kind of acceptance testing in there, then that's why I was saying this is a huge category outside of the things that you can do with just automating, like acceptance testing part of that is like user experience testing is I would put it in that kind of category and that's why I say that one's kind of so huge and so big because it's not just reliability or scalability or anything like that, but how getting it to an actual person and making sure that they can use it and it functions kind of as needed. So we do a lot of web development, obviously building lots of websites and we do user experience testing as early as possible. If we can do early research, we'd like to help our clients make good data-driven decisions and if you have a technical mindset, going in and diving into the data and coming up as to why they should not have the CEO's face on the homepage and being able to go into that with a lot of ammo from a technical side of things as well as from a user experience side of things. I mean, data is power. I always try to build in wiggle room. Wiggle room is actually a technical person's best friend because they're very used to making things very concrete and solid and it's really important to build that wiggle room. So on a 3000 hour project, a lot of it starts off with discovery. We need to actually learn, how do I know from a five page RFP that I'm gonna be able to actually deliver on the scope of work? So having that discovery, but then it's taking also bite-sized pieces because it's a huge undertaking to understand the scope of that size of project. So you're like, okay, I'm gonna talk about this specific thing and kind of dividing it up into pieces that you can then further break down. And sometimes and often it means saying, okay, there's a huge solar component to this and they want all this craziness. I'm gonna talk to our solar expert and ask four or five bullet points on what we're like a paragraph from him and then okay, they're really stuck on using Bootstrap. They won't use anything else. Do we want to talk about whether we use SAS or less to build that? You know, like we can go into those conversations but discovery and building yourself in the wiggle room, especially if you're a really smart person that wants to like figure out the solution. You gotta figure out the solution but then if or then what? Or you know, all the different variations so that cause the clients will inevitably come up with things that weren't even thought of then. So, yeah, scoping is a really hard thing to do in general and I do think it's just time, lots of time, lots of mistakes. Yeah. One, two, one, thank you everyone. Thank you. And if you want to find us, we have another one here. Yeah, so if you go to the like con site or we'll be up on there, like we have a link to it and you can go and you can provide feedback. You'll also be able to get all of our slides and we will pop in our contact info and you can access our Drupal.org like usernames and profiles in there. We're fine. We'll post it using the TPM hashtag by end of day so you can keep an eye out. And we also, I have a booth at 701 with Canopy Studios. You're welcome to pop by there and or grab my card after and I can connect you afterwards. And I'll be chained to the Pantheon booth giving demos all week. So I will be super easy to find, look for the bright yellow B-like t-shirts that we'll all be wearing. I'm sure you've seen them. Very flattering. Cool. Any other questions? No. No. It's a very funny thing. I am not, I went to school to be an entrepreneur and I never thought I would do that and I never thought I'd work in technology. I was the girl who didn't know how to get into my website and was like, five different steps to upload an image in Drupal. This thing's so dumb. I came out of the world of flash and I thought flash was like the coolest thing and then we had to move into this content management system. So all of my training is come from the School of Hard Knocks. So. Likewise. Yeah. And there were a lot of hard knocks but fortunately to the smart people and I gotta say the community has been absolutely a huge part of that experience and learning. Going to sessions. I remember when I was going to those sessions in 2008 I would go into the most technical thing and just write everything they would say down and then I would be like, I don't understand any of this and then spend time with my community asking questions because Drupal's got this weird language. It seems so much different. Like we don't really build Gantt charts at work. We really don't. I keep thinking, oh we should build this Gantt chart. No, we're just in our whatever process. Yeah, there is a really cool digital, what is it called, the digital bureau and they offer a technical project management training and we'll be attending that this year. So I think that anybody who wanted to go outside of the Drupal community get training. I think it's called the digital bureau summit and there's one specifically for people. It's gonna be in the links. We have that in there as well for the resources that we're gonna share with everybody later. Cool. One last question. One, I can actually post up this really cool kind of world clock where you can find things that are within people's working hours. I think you can add in like up to four or five time zones. For time zones scheduling, there is also like a little kind of widget that's in Google calendar where you can select a bunch of different time zones to display and when you're scheduling a meeting, you can see the time that it's gonna be in every single one of those time zones. Cultural barriers, like again, this is why it's really important to get people's faces on a hangout because if there's a barrier for language, it's really, really difficult to understand like a secondary or a tertiary language if you can't see somebody's face and you can't see the way that their hands are moving. It gives you a lot of context. Cultural, I don't know. That can be a really thorny question. Maybe don't talk about politics or religion or... I would say that for time zones, make it equally uncomfortable for everybody. That's a really good tip. Get equally uncomfortable. So we're primarily West Coast. Some of our East Coasters have to stay out to eight or seven or eight with us. Some of our West Coasters have to start at six sometimes. We have one of our friends who lives in Turkey and he is, he's a wonderful developer. He's super strong, but sometimes his directness comes off really, really strong with clients. And honestly, we're very honest with our clients to say, hey, our friend Bakir here, developer Bakir. He tends to be very direct. He means it in the best form possible so to preface your clients so they know that. Or as Danae always says, she's gonna be the meat shield. She's gonna stand in between that and help be that barrier and that communication. So definitely interesting in our global world and it's getting smaller. If you have any questions kind of after this, you'll know where to come find us, to reiterate, this is who we are and kind of where we work. And then if you wanna follow up later, I think we put, yeah, this is gonna be the link for the session. You can also just kind of search within the sessions and find us there. Thanks everybody so much for coming. We really appreciate it. Thank you.