 Thank you everybody for joining us this afternoon. Today we're going to be talking about support, how to make it fun and profitable. My job in support is to really keep the queue calm, keep clients happy, and keep things planned. After three, I'm a support developer and I also help all the whole support dev. Here I'm Scott, I'm the director of customer success at Pantheon. Prior to that I worked at type management services in IT, so I'm here to talk about service design. I'm interested in working in support, actually actively looking for support or help. Appliers or issues are usually not very calm on the national objective and how can we quickly overcome it. Michelle's going to talk about onboarding clients for success through an auditing process, and it's often going to go on to talk about more service level agreements, but I find that regardless of process and structure, you really need to first figure out what hiring needs are. We're working on production, things move fast, but large chunk of them don't feel very safe and secure. They've maybe been in a past situation that has caused some current pain. Maybe you guys have experienced those intents. And as you jump online, they're all over you, or they're sending you five emails a day on the same thing, or maybe they're really hyper-intensive when we're talking about making clients feel safe and secure in support, and applying to their email, answer their chat. It doesn't mean you have to do the work right away, but if you acknowledge them that they're heard and that you give them some structure and some extra budget intents of clients, it's what's going to talk about service level agreements, making sure they have some expectations around how much they're going to spend everyone. That helps them a lot, especially if they've come from a place where maybe they got burned with big budgets or costable work. When it comes to developers, they're on the front line, managers and project managers, to make sure that stuff gets done as quickly as possible, but we also want to make sure that the devs have someone to turn to. They have someone to ask questions to. Clients are getting more comfortable working with us. There's now the sense of belonging. You find that when you have support routines and things are in a patterned motion, that clients soon become very comfortable working with you, collaboration, post-questions or challenges where they're stuck. This is often a client that's been working with you for maybe a few days, maybe a few weeks, maybe a few months. They're showing off the work that you've been doing in the queue, their problems, they're collaborating, they're working together, and I find one of the most important things in client services is to recognize a job well done. As a hierarchy of needs is actualization. So this is when the queue is calm and stress-free. And I find that when you're working with people in support, it's really easy to get bogged down in the fire nature of the tickets. In the end, we may be saving lives in other ways, but it's really important to keep things calm and stress-free. Think of the supervisor of an apartment building, but a superintendent, you're responsible for fixing stuff, those situations where you have the best intentions, then you have to start. This was a pretty famous study that was done both 1996 and then again in 2006 was just about the same result. So when managers, when I see managers were asked, hey, rate your projects. How would you rate the relative success of all your projects? This is what they said. 50% of IT managers, they have 53% of their projects are project challenged. It's about checking to check exactly how that is project challenged. So doing an inspection of the building before you become the supervisor of it. Things that I have noticed in my auditing are project challenged. One of the ways is if they have a WYSIWYG theme, the types are just titles and body fields, WYSIWYG on. They've got images and tables, and it's just all stuck in the body field. It's not available to Drupal. It's not available to create video libraries and pull from the body field the videos. You can't pull the images. They just have to know how it looked. A quick check. Of course, you're doing this locally. You would never do this in a live environment. But you just turn off the WYSIWYG and see the project challenged. Is that they have hide and seek PHP. They like to hide in the global fields. I'll talk about this in-line PHP, so they have their P1 script. It calls a script which was in root, card coding credentials, and functionality of the database. It doesn't cache for one, so I can't solve any performance issues. It's really difficult to trace. If there's functionality going on on the website that is just in the database, it's just full places. You end up with 16 hours of work for something that was supposed to be really simple. It also doesn't export well. So these developers would never put PHP in-line. Secret mission modules. The secret mission modules, they have a function. They get it done, but they can't tell you what it is. It's super secret. The developers just made it really difficult for you to figure out what was happening. This particular module starts with an apology to the person who's looking at it, that they're not entirely sure what it does, but it does it. So I was just having a conversation now with Megan that one of the biggest challenges I had at support when there's custom modules like this is no matter how much documentation that I provide in an audit, no matter how clear I could be about what's going on here with how this site works, if it doesn't follow best practices, if there isn't a clear Drupal structure to this, this is completely how much I look at it, no matter how much I write about it. If I created a wiki for it, it just lives inside my mind how this particular site works, and I'm attached to it in a way, that structure that is just so deviant, because it means you're stuck with it. There's a lot of scripts that are out there that check for complexity, for copy and paste from Drupal standards that I can run inside a vagrant box to report. There's a lot of helper modules that can help with this. The modules also like to hear how you figure out if they're custom modules or are custom modules, and see what it does. Code-based quarter. These are not your container store. So you could just see what modules are enabled on their site, and go find them, to see if you could figure out where they are. There was an electric support developer who was running the module's making sites, and there are tools to help with this. I know there will be a ton of sessions today talking about that, but that is the dream. In the meantime, I would like to at least stop these, and they're just a patched up, PHP scripts, poison, sadness, and other core shops or contractors that have a view to support you should, because it changes the way you think about things. If you have support developers whining on feature shit, then you can have developers who are facing the configuration code, including all configuration code. There's so many modules out there right now features the configuration module will export all these things. There's really no excuse anymore that simple tests can be hairy, so fine. A lot of naval gazing in the developer community and why can't we build stuff out of cathedrals? Why can't we build things that last for centuries? When this became a question and Linus came around and said we'll just have everybody look at it. If there's enough eyeballs on it, Drupal will be complete. Our patients come to me, prevention is better than care. It's way easier to try to prevent issues from happening than solving them. Major functionality is not there and you're working on a production server. As far as how I think about doing development in a support environment, I find that it's really useful to take a step back. It's an open source project. There's thousands of contributors. The state of core and the state of contrib is constantly evolving. You're working on a support site. The ecosystem is even broader than just the Drupal code base itself. It's really a dynamic thing that includes timelines, budgets, your state of your servers and how it's been super interesting for me. I actually get to see firsthand how Drupal sites that folks, all sorts of different folks build hold up over the long term. I get to actually watch where them. Just in the same way when you're building a Drupal site, you can make major architectural mistakes that perpetuate those existing, initiate some of your own. I want to share with you guys 10 Drupal diseases that I find that are really common in support process function. You're overriding a template and that is generally how easy to accidentally override your override. The best Drupal sites when they're architected are modular. They're using code. They're kind of such an easy thing to do. Huge. You can go and find a module that allows you to deploy things that you wouldn't otherwise be able to encode. But sometimes, you know, you have to be really thoughtful. So to me, that means, you know, good commit messages should be able to turn a feature off. You want to make changes, new features, and do work on the site. Maybe there's some big issue you're trying to clean up. And the philosophy I like to take when doing development is try to avoid, try to do not and kind of get in and get out. So understanding what were those fundamental decisions is important to have like a system for escalation. You don't necessarily want, like, us who have to jump between cloning to it, which might take 20 hours. So I think what the idea of what's sustainable is actually like a pretty big spectrum. And both answers can be right and wrong. So the most is technical solution in the beginning. Most of the response time is actually trying to figure out. Usually, once you know what's broken, it's much easier to find a solution. So the first question I ask myself is, okay, so once you can reproduce it, then you can start to kind of dig into it because it's something you kind of learn to live with because it just happens every day. And it can be kind of scary when you're first getting into it, but what keeps it really good for me is when it's just simple and it's really... All right, so if you've gotten the theme here, we've all sort of picked what departments are great intended and the psychotherapist. And so what I thought of was, whatever, so if someone came in and they wanted lasagna, I'd figure out how to cook in lasagna and I'd make a birthday cake. And I'd build this whole restaurant that was based on no menu. I've seen Kitchen Nightmares. I know nothing bad can happen with an idea like that. So I tested it out and then I decided finally I hooked to the first table and they say, I like this place so much that I'm going to eat and that's kind of how I think of how to support kids. And so the reason that I thought of that was because long before I got into IT, I was a good musician, so I got to be a really good waiter and a really good bartender and well, not so much a good bartender but a good waiter. So a lot of what I've learned about IT and development and Drupal came later, but a lot of what I know with customers came from waiting tables and working with mannequins so I'm going to share a couple platitudes about that kind of time. The first thing that I always thought is to run the table. When you walk up to a table and you're a waiter and you say, well, what do you guys want to do? They'll say, okay, well, get me a shot and then you run back and they'll say, we'll get you four waters. And then it's already out of control from the beginning. So this is like, there's two keys to success. It's important, like it's the people and then it's the processes. So the people part of it on your side means training your people to use the words, like empower them to solve the client's problems and sort of explain what that means in really clear detail because, you know, support and projects can be very different. Like support is long term, it's a short life cycle of finding a solution and implementing it and so the life cycle for that doesn't really work very well. So being able to have something where you never know the expectations of how to solve the problem. The next thing, you know, to say that for performance and like the military version of that is we don't rise to the occasion, we sink to the level of our preparation and so like delivering support, especially for now like in Pantheon, workflows are really important and that's sort of the processes part of it, you know, being able to escalate an issue sort of like these developers are great and they've just sort of given you like growing something at them and saying fix this, I don't know how you're going to do it is really important to the success of your department because no one's going to stick around, you know, if they sort of feel like an escalation form issues versus site specific issues and especially if you're doing posting like that's a really important thing to be able to manage. So then things sort of drilling down a little bit is when you are talking to a client about what they want, like the 3Rs that I learned when waiting tables were read it, write it and repeat it so you actually read over the menu over their shoulder at what they're pointing at and then you write it down so it's written and then you repeat it back so there's complete, if you want to order the drink you actually have to be able to say the drink that was usually like a warning you also talk about support in the same aspects clients may just because they're not sure what they want to stop them from asking for it and being able to go back and forth until you're completely clear about what they're actually asking for you know it's kind of like projects you know a lot of projects aren't really lost in execution they're lost in the discovery part of it where you didn't do enough sort of projects are pretty familiar with the project life cycle I think when if you're looking to start support or looking to build your support to services there are frameworks for this stuff and itel was one that I used in managed services before I got into sort of Drupal and managing development support teams and that sort of thing and itel and IT service management is another sort of tool that gives you a really good framework for building support and building services so the strategy part of it is sort of figuring out what there's market demand for and if you have the skills to fill that I think that's really important with the support like the way that you can pay a support team is by trying to deliver everything that we previously was sort of using downstream providers for services and I think that model applies really well to Drupal if you can apply it right I think there's there are shops that I know of that are great like CBCRM and support when you need it if you can sort of set the terms correctly so designing you know coming up with the strategy and then the workflows kind of the next step the design step how are you going to escalate how are you going to make this actually work and sort of testing for you know edge cases which are going to be the ones that are going to to stick you so you designed it then you actually put it into place and you practice it and you monitor it and you actually see how it's going like one of my favorite things about my job is sort of improving the process like the at Pantheon enterprise clients would come up and we'd sort of feel their struggle and they'd open tickets like they normally would but we can tell that they weren't happy and one of the first things we did was put in an onboarding process and putting our onboarding process now it's you know as imperfect as it is it gets better and better and the results are lower support tickets for the long haul and you know like not all clients want to do that these last you know the 10 diseases that sort of thing they weren't made up because people these problems and so I have this laundry list of the top things that developers run into when they're so whether people want to or not I set up a call with them where I just read the list and you know I don't know if they're asleep on the other end of the phone or if they're I'm setting expectations and I'm letting have these problems I can say well we did try to discuss this about onboarding and most of the time it doesn't come to that like most of the time the whole sort of pigs versus chicken thing it puts more sort of pigs into the into the mix here and there's more stakeholders involved especially getting everybody involved the stakeholders involved in the entire process of transitioning to support and then so just a couple things about the tools you know like I had mentioned support really is its own workflow it's not like a traditional project management being able to have the process and have it down so cold that like as far as tools one of the you know one of the best tools that the tools are sort of custom to what support you offer but for me like when I worked in managed services you know we were doing like IT support for servers and that sort of thing typical Cisco Microsoft products you know you didn't know you can basically make a living just supporting those two products and so that's what we did and we go to small businesses and do that and so our tool was really good at managing different configurations of block hours that we had with people with you know managed services agreements that sort of you know takes a lot of time out of the project manager or support manager's hands and you know now we use like because we're also doing onboarding we're doing some training stuff that sort of thing desk because it's really flexible it has a lot of inputs and outputs to connect to different applications and we use do.com which has been a life saver for me for these sort of things. I think that's a really good thing to do and I think that there are a lot of things that we do that we do over and so like contract design like I sort of just mentioned I think that the amount of risk that you sort of your gut check tells you that a project is kind of determines how you should shape your contract. I am a firm believer in making contracts easy and so I think simple contracts that are sort of based on either block hours, monthly recurring and block hours are sort of the highest risk thing if a guy comes to you and says I'm a PHP developer and I have to finish this project and you have a risky project so you do not promise to do it for a fixed fee. I mean obviously you know like fixed bid for something like that and they're still risk about it but like the less amount of risk I think the goal is like the more times you do things and the more you specialize you probably have a better chance of knowing what the problem is when someone brings in a CBCRO problem and there's less risk and you're more able to sell that as sort of a monthly recurring thing rather than a and so finally like the main point that I wanted to talk about is that like burnout exists like it's really like these guys need to have fun you know no one is in support both that are in support are special people like they're facing and they have the technical chops so I think you know with us I really sort of stress being able to spend time on other things and also like I mentioned earlier empowering the team like letting them have say over what kind of work it is a team effort and it's real so for whatever time we have left that sort of bar should be ill ideas about different questions that we had but you know we're open to questions now and do for FEMA we have a little situation in Oklahoma what we're trying to do right now is pull together a code starting at 730 at the DoubleTree Hotels Coders Lounge have a very specific need we have a very specific goal what we'd like to do is effectively build a website that will help us coordinate transportation needs and housing needs and so we basically have four pushes we need people that can code for the housing we need 730 tonight Coders Lounge I have a specific question I think we have a smaller team than you guys so we don't really have that chain of up and down but my question is around you're a nice person you want to help people but what about those clients who are out of support but still keep asking your questions and how do you handle user acceptance like bugs or bugs happen like I think that's important like something that needs to be addressed in discovery it's such a common thing that something turns up that necessarily every billable hour needs to be billed like there's a difference between actual and billable but I think you said I'm able to staff for your SLAs two hour turnaround make sure that there's someone who's willing to have the people also be able to handle I think there's a lot in analytics like there's probably trends whether you know or don't based on just the amount of tickets the typical sort of budget planning like how many sales protections means how many tickets each ticket takes X amount of hours you can come up with a rough model like that just a simple linear regression like I just sort of looked at our past history that I explored at a desk and built it off of that and it's pretty close I mean there's a relatively high error but it's sort of also based on being able to have a pretty amount of response time which we sort of guess at because we don't track the time