 Good afternoon, everybody. My name is Scott Weston, and I'm here to present my thoughts and approaches on how to build efficiencies into Drupal practices. How has everyone's con gone so far? We made it to the last day of sessions, the last session block. I'm sure there's a lot of session fatigue at this point. But hopefully, I'll be able to give you some really good ideas and information through this presentation. Some of the presentations I've seen, even in the project management track, have been amazing. So I hope that I can provide you with either a good summation of some of the things that you've heard this week, or maybe even give you some new ideas that you can take back to your home organizations. If you want to follow along in the slides today, I have this presentation set up on GitHub. The address is nodeloophole.github.io. And that's my assistant Mordekai. He likes to help me when I do my Drupal coding. And I'll have this URL on the next few slides as well if you want to follow along. As I said before, I'm Scott Weston. I am a solution architect at HS2 Solutions in Chicago. I've been doing Drupal since early Drupal 6. Before going to HS2 Solutions, I led a small Drupal practice also in Chicago. In my free time, I enjoy bowling and darts, and I've recently picked up running, which is going pretty well so far. As I said before, I work at HS2 Solutions. And at HS2 Solutions, we strive to be really a trusted, responsive, and effective digital transformation partner to some of the best companies on the planet. We do this by valuing smart strategy, great design, awesome engineering teams, and working with people that are passionate about what we do and our clients and our partner agencies. So the purpose for my talk today is I want to give you some information and thoughts and ideas about how I've seen that we've made our Drupal practices more efficient. Now, I don't think I'm going to cover anything revolutionary or groundbreaking for you today, but I hope I can provide you with information that you, again, can take back to your practice and help it become more efficient. And I framed the presentation today around four main questions. What types of skills make up a great Drupal team? What are some practical ways that a Drupal team can increase their efficiencies? How can a Drupal team stay motivated when being asked to do a lot of work, especially under deadlines? And how can project managers help with efficiency? So let's just dive right in and start talking about skills. The basics are really straightforward. We have the direct skills that any person needs to be able to perform their job. So PHP, knowing some Drupal, knowing a lot of Drupal, in some cases, CSS, JavaScript, Symphony, Git, those just kind of meat and potatoes things. And then there's also the related skills, which are the frameworks, knowing some DevOps if needed, some server management, knowing things like search APIs, knowing how to interact with REST or SOAP. Those sorts of related skills are always helpful. But there's this other area that I call soft skills. I think it's just kind of a term of art. And these are skills that aren't easily measured. They're not objectively measured. They're more subjective. And these skills are sometimes overlooked, maybe in the interview process, or overlooked if a developer or someone on the team is a rock star in many other ways, but they're lacking some of these skills. I say that some of these soft skills can be just as important as the direct skills that an individual may have. And as we go through these skills, if you see these traits that people have, you can see how having them can help your team function at higher level and with more efficiency. I think the first and most common one that everyone mentions is communication. So this is, can an individual articulate ideas and thoughts speak up if they're having problems? Do they engage in active listening? And do they understand the message being conveyed to them and understand really what they're conveying to other people? Another kind of facet to this is using the correct voice. So an example I like to give is if you have two developers that are talking to one another, they're going to have a really technical conversation using very technical terms. And packed into that are a lot of assumptions of what the other person knows. But if you put a developer in a situation where they need to explain a technical concept or a technical framework to someone who's less technically minded, you want to ensure that your developers can do that and not be too abrasive about it or to condescending about it at times if someone doesn't know a technical term or concept. So you really want to look for those people that can articulate those things. Another facet of another trait of people that I like to find is have people that have a bias towards action. And this is just people, someone that is ready to get their hands dirty and start solving problems. As we probably all know in Drupal, there are 10 ways to do any single thing. And there does need to be a balance between research and discussions and actually taking the action to do it. So you want to find people that know how to do the right amount of research and deliberation and then make a decision and run with it. You want to try to avoid situations where you put someone in a space where they have decision paralysis if they have 15 different options of a way to approach something and they can't make a decision. You want to make sure that you are empowering people and giving them the confidence that they need to know that you're going to stand behind the decision that they make and you're going to work with them to see that decision and that approach through to the end. Another trait that people I feel need to exude when they are working on a team is the trait of constant learning and constant mentoring. So you want to find people and you want to encourage in people a growing knowledge and experience, growing their knowledge and experience to a higher level. Someone who is constantly striving to learn more and learn more about their craft, learn more about the related skills is better prepared to solve potential problems before they become really big problems. And this proactive response to situations helps minimize rework, bugs, and problems down the road. Someone that recognizes the value of sharing information with others is an asset to your team as well. They know that doing so, sharing information, elevates everybody, elevates the entire team. And in that respect, your team as a whole becomes more knowledgeable and more efficient. And someone who takes ownership knows their responsibility to see a task through to completion. If they don't have the necessary resources or information, they find them or they find it. And as a project manager or another team member, you should have confidence in knowing that when a developer or a team member takes on a task, that they will see it through to completion. Of course, if there are blockers, they should surface those to the team. And if they are not full blockers, maybe just speed bumps, they should try to work through those so that that task or that assignment can be completed. And a developer or team member should be able to know where their focus should be at any given time. This is particularly useful when, let's say a developer is on multiple projects. Knowing of their competing priorities, which one is most important is critical. Part of focus is also the ability to say no or not right now to incoming requests that don't help achieve the highest priority for that person at that time. And some developers are people pleasers. I know I've fallen to that category at times and if I get requests coming in, I want to be the go-to guy to get things done. So sometimes it's hard to say no to someone, especially if it's a close colleague. But having that skill, that trait to know that I have to do this other thing and I must say no to you for right now, that's important. Also important is the ability to push away distractions and other sources of wanting your attention. So this would be social media, email continually popping up and just going to check it constantly, things like that. Just knowing when to shut those things off and move on to the work at hand that's important. So kind of the takeaways for this section for me are when interviewing job applicants, ask questions that will uncover obviously the direct skills but also some of these soft skills. So for example, assume you are involved in the interview process for a developer and you want to tease out if this person has good communication skills. You could pose a question something like, assume I'm not a technical person, please explain to me how views in Drupal works. And you may know how views works, you may not know how views works, but just from the tone and the content of that response, you should be able to know does this person have the ability to articulate technical concepts in a non-technical way. So you want to frame interview questions around those traits to just know if the candidate is someone that would be well suited for your team. And then with your existing team members, look for opportunities to highlight and encourage and strengthen these strengths when you see one of these behaviors exemplified that you want to enforce within your team. So once you kind of know what you're wanting to look for from the direct skills and the soft skills, another aspect is to just make an assessment of your current state of the Drupal team that you have. And this is an opportunity for you to have a good baseline measure for where your team stands today. And it's also important to be very honest about this. This is gonna be internal, this isn't gonna be posted on your website. And it will really inform your organization about the strengths and the weaknesses within your Drupal practice. First, you want to look at technical knowledge. So if we're talking about Drupal practices, we need to assess Drupal skills. And when doing Drupal skills, you want to get really specific. You don't want to just say, do they know Drupal 7? Do they know Drupal 8? Do they know front end? Do they know back end? You want to dive deep into this. And you want to know, ask very specific questions like, does this person have skill creating field formatters? Do they know how to use twig templates? Do they know configuration management? Do they know how to write an event subscriber? Do they know how to work with render arrays? And if the project managers in here can take this information back to the practice leads at your organizations, they'll kind of get the gist of what we're looking for. At HS2, we started a skills assessment of our Drupal team. And I think we had 120 data points that we were collecting on each person related to the skills that they had in very specific areas. So you can get very granular with this. And then for courses and certifications and awards, you'll want to collect and maintain a list of those as new certifications are bestowed upon your team members, add those to the list. And on the last slide, I know I said that this was for internal only, but for the courses and certifications and awards, these can be a really good selling point to potential clients. So they can be very helpful in responses to proposals or asking for proposals. And when someone gets a new award or a new certification or completes a course, that's something that the entire team should be celebrating. You really need to create an atmosphere where victories are celebrated by everyone, not just those that achieve something. Also part of the assessment is domain knowledge is what I'm calling this. And this can include work that members of your team have done in other industries before they worked for you or worked as a developer. It can also include the type of websites or types of clients that each individual has worked with. An example here would be, let's say that one of your developers worked at a financial firm, an accounting firm, before arriving at your door. They may have some information about regulatory matters related to financial firms that when you're trying to pitch to an accounting firm to do their website, they may have some, not necessarily insider information, but they have some insight into some of those things. And you can surface that during the pitch to let your client know that you have expertise within that domain. And that can definitely help the selling process. And also knowing this kind of information can be helpful in knowing how to staff new projects that are coming in as well. For assessing the Drupal talent on your Drupal team, some takeaways here. After you've done this, you should have a sense of what type of work to go for and which ones would be the low hanging fruit to go after. You should have a good metric of your team's strengths and weaknesses and being able to find ways to improve. You should be able to identify some concrete next steps that your team should take to help them level up. And kind of at the culmination of all this, you should have a nice roadmap for improving your team. And it's more than just having that roadmap, you need to work it and get the knowledge and information and experience leveled up so that your team as a whole increases its knowledge. So getting into the guts of what we're talking about today is increasing efficiency in your Drupal process. And I'm gonna take one step back and just highlight that efficiency and productivity are not the same thing. They are related, but those terms should not be used interchangeably. Productivity is a measurement of number of units produced. Number of units produced could be number of lines of code, number of tickets cleared, number of story points completed in a sprint. It could be anything along those lines. And then efficiency is how much resources or how many resources were used in the production of that unit. And the way to increase efficiency is to reduce waste within the system. And when we're talking about development and programming, waste could be a very specific example would be dealing with a slow development environment. If you could speed up the development environment, you might gain some efficiencies there or reducing the amount of bugs that are generated or the amount of refactoring that is needed because of maybe ambiguous requirements or some improper assumptions that were made on behalf of a developer when looking at wireframes. So anything you can do to reduce the waste within the system, you increase the capacity to do production to produce more. So with that in mind, as I keep talking about efficiency, know that I'm wanting to give you the tools that you need to increase that efficiency so that you can produce more with the same amount of time and staff that you have now. So before project even starts to build, it's good to have a meeting with the build team and just make sure that everybody agrees on the work to be done. And this can highlight what's in scope, what's not in scope. So for example, if you have wireframes that contemplate multiple phases of a project and we're talking about phase one right now, be sure to highlight the things within the wireframes or within the requirements that are out of scope in that current phase. And I'm gonna stick a pin in that, talking about multiple phases. I'm gonna come back to that a little later. Another common point for everyone to be on the same page about is what does done look like for this project? Is it a proof of concept? Is it an MVP? Or is it a fully fleshed out site? So as long as everyone's on the same page, what done looks like, that helps keep everyone focused in the right direction. And then have common names for everything on the project. So a perfect example I can give is I was recently on a project for a website and I'm gonna use ambiguous terms to talk about this. We have this thing at the top of the page that had a big hero image and some text on it and every five seconds it switched out to another image. I called it a hero rotator. Someone else on the team was calling it a carousel. Someone else was calling it a slideshow. And we had these terms in our head about what we were calling this thing. And so we were having a meeting and I was talking about a hero rotator and my colleague was talking about a carousel and I thought he was talking about something else. So we had to like have a level set of, okay, this is the thing we're talking about, right? The thing, and we had to point on the wireframe to this is the thing. So if you can have common understanding of what things are called, that's great. Another example is with more than one client of mine and I've worked with, they call a region on a page that does something like a newsletter sign up form or related stories, a block on the page that does something, they call that a module. And in the Drupal space, a module is something totally different. So even aligning what you're calling things between the client and the team is helpful and you may have to make a translation table and say, okay, when the client says module, they mean this just so that there's a common understanding so that there's no miscommunication or reducing the possibility for miscommunication among the team and with the client. Also before the build starts, there should be a solid plan. The lead developer or the architect, the Drupal architect for that project should create a plan for the team to follow. And in this, you should resolve as many unanswered questions as possible. A smart Drupal architect or senior developer, lead developer will be able to look at wireframes, look at requirements and really have some long-distance vision and try to ask questions that can be problems later on, especially if wireframes don't have 100% fidelity if they were just kind of inspirational wireframes, so to speak. And along with the plan should be a solid content model and that includes things like content types, taxonomy vocabularies. I would also say roles and permissions, modules to use, modules that will need to be built, custom things. And I do wanna point out a few years ago, I think maybe more than a few years ago, Palantir.net published a blog post and I've linked it here and you can get it in the slides as well, to a blog post about a build specification and they shared a Google doc that is their build specification. And to be honest, it's a little dated, it's for Drupal 7, but it can be, you can copy it and adapt it for your particular needs. I think I would recommend this as a great starting point for creating that kind of nuts and bolts build spec plan. So definitely check that out. Another way to increase efficiency when you're actually doing the build is to have standard tools and processes. So standardize the toolkit for everybody. And I go so far as to say computers, IDE, other software that is used in your practice should all be the same. So if everyone's on Windows or everyone's on Mac or everyone's on Linux, that helps a lot. That means the team can actually help each other and they would in theory have the same problems and be able to help solve those quickly. And then the development environment, everyone should be working on the same type of the development environment, whether it's Acquia Dev Desktop, Drupal VM, or some kind of homegrown, vagrant machine that you have. And it should, aside note, it should closely match as much as possible the actual production environment so that behaviors are the same between Dev and production. And I would also recommend having, across the entire practice the entire organization, having the same project or task management process in place as much as possible. We know for particular clients, for particular projects, there are some little nuances. But insofar as you can, have it the same across the entire organization. And kind of going along with the last point of having Common Toolkit, have a common starting point for all of your projects. And this is probably some of the most drooply stuff that I'm going to be talking about today. So I can describe what we do at HS2 Solutions in some detail. So maybe this gives you some inspiration or ideas that you can take back. So at HS2 Solutions, we have a base Drupal installation profile that we use for Drupal 7 sites and Drupal 8 sites. And what we've kind of baked into our secret sauce in this installation profile are the modules that we know 90% of our sites are going to install just a matter of doing a website these days. So things like Google Analytics. In Drupal 7, having Path Auto, just any of those kind of common, give me modules that every site has, we have baked in an installation profile that takes care of that. I'm sure many of your organizations do that as well. If you don't, I would recommend going for that. It gives you a common starting point and it gives you, for the industries that you work with, the areas that you work within, the spaces you work within, it gives you a leg up on the build out, which makes things much more efficient. Because one of the things we wanna do is reduce the repetitive work or the duplicative work from one project to the next. And going along with that, don't try to reinvent the wheel. And particularly with ambitious developers, this is a problem sometimes. I can say that from my personal experience in my younger development days. Try to avoid doing things radically different each time you build a site. The example I always like to give is that hero image rotator thing that we were talking about a little bit ago. How many different ways can you really build that? Why are we building it from scratch every time we're building it? Why don't we establish what we're gonna use, whether it's some carousel JavaScript library or some homegrown solution, and let's just run with it. And then we can build on it and iterate on it so to incorporate new features that come in into play for the particular projects that we work on. And leveraging the knowledge you have rather than investigating new things at times is good. Sometimes it's appropriate to do something totally new and totally radical, and that's great. But sometimes it's also good to stay the course. As project managers, this is something I can, for you guys as a developer, talking to project managers, as much as you can, let developers develop. And in your organization, obviously every situation is different. But there are little things that add up in a developer's life really quickly. Things like, oh hey, can you go look at the printer and see if you can make it print my spreadsheet for me? Or meetings where the developer doesn't really have a role or have an objective of takeaways in that meeting. If you have an hour-long status meeting with a client and the developer, you want the developer in there just in case some technical questions come up. It might be a better use of time to let the developer develop for that hour and then have a 15-minute follow-up with the appropriate stakeholders if there are some technical questions that come out of a meeting. Things like that. And it's also okay to have specialists on your staff. And I'm not talking about putting people into a silo. So if someone says, okay, Scott, you know search APIs like nobody else in this organization. So any project that does search, we're putting you on that project. That's not what I'm talking about. What I'm talking about is knowing that I'm that resource, knowing that Scott's that resource, if someone has questions or problems or needs pointers on how to address search API questions, for example, and surfacing that to the entire team so that you have that well of resources across the team that others can plug into. This one's kind of a gimme. Follow good development practices. So do the basics, do them well. This includes coding standards, peer review, documentation, doing things the Drupal way. And how this really helps with efficiency is if I'm airdropped into another project, I don't have to orient myself with how the project is built. If I know we're following coding standards, I know how to find the code that I need to find. If we're doing things the Drupal way, I know what hooks to look for or what event subscribers to look for, what, you know, if the organization follows certain naming conventions for custom modules, I know what to look for. So that can help with efficiency, especially when transitioning off or onto new projects. Next is to build with the future in mind. And a little while ago, I said I was gonna put a pin in wireframes that had future phases baked into it. So I'm coming back to that now. So where possible, if you know where the site or the project is going that you're building out, and you can lay that foundation today in phase one for phase two, that's a great win for you and the team as well as for the client. Example I like to give for that is, let's say that you're building on a site that has kind of a help and how-to section, just articles about how to do random things. And let's say in phase one, you're going to have a field that is a skill level. So basic, beginner, intermediate, and advanced. And in phase one, it's just going to appear as a label at the top of the article, that this is an intermediate article, for example. The easy route is to just build a select list field and populate it with beginner, intermediate, and advanced, and then just display it. But if you know in phase two that there's going to be a help and how-to landing page where some dynamic content will need to come into play, maybe a full description about what the difference between basic and intermediate and advanced is, you might want to go ahead and build that out as a vocabulary, a taxonomy vocabulary, and create that entity reference. That way when phase two comes along, you don't have to do any data migration, you don't have to destroy anything that you built in phase one, and you've laid the ground work with minimal additional effort for that future phase. Another aspect is to invest in everyone's continued growth, and this is talking about experience as well as just knowledge. So investing in training and education within your organization, encouraging people to attend or you may be even hosting local events like meetups or camps, and then also having internal training. So just at HS2 Solutions, we have a quarterly Drupal meetup that's just internal to the company. So we all converge on home base, and we have a one day or two day meeting where we talk about how we do Drupal, what projects we've worked on, things that we've learned, and just a really good internal information share. It's basically like a mini camp, but it's just for our company. And that springboards into contributing back to the wider Drupal community through presentations at camps and cons. And also for project managers here, as much as you can help people avoid multitasking as much as possible. So this is working on multiple projects, seemingly at the same time. There are definitely real time costs to task switching. So it's better to time box efforts into larger chunks if possible. And as much as developers will fuss and fight, if you know you're gonna have multiple meetings with a developer over the course of a day because of project kickoffs and status meetings and that, try to schedule those back to back to back so that everything's compact as far as meetings go. And that gives a bigger chunk throughout the day for doing development work. And you may have to explain the why for that, but that is actually helpful better than having meetings staggered throughout the day where there are seemingly small chunks where a developer could develop. Another one in this one hopefully is common sense and obvious but fix bugs immediately as they're uncovered. If you build on top of bugs, it may cause more bugs and then you'll have like an infestation and that's not good. And if you ever hear the phrase we'll fix it in QA, it's a very dangerous phrase to hear and you definitely want to tamp that down and get that idea out of people's head as quickly as possible. Litting bugs linger can only cause more problems. So for increasing efficiency, some takeaways, look for opportunities within your Drupal process to increase efficiency. Look for the things that are inefficient. Try to eliminate duplicate or repetitive effort where possible, try to automate some things, get some nice starting points set up for the practice and invest in people, letting them work and also let them work the work. Those are kind of the key takeaways for me in keeping the team efficient. And sometimes developers are called upon to do some pretty heroic things related to timelines, working a lot and that sort of thing. So how do you keep the team motivated? And you want to avoid overworking people and you also want to give them something new and exciting to work on. So what can we do? And some of these are pretty basic. One is strive for daily productivity, daily production. When I do a task decomposition for a project, I try to keep any single task at less than one day to complete. So if you have a task that's like a multi-day task that you know is gonna take 12 or 14 hours or longer to complete, try to break that down into smaller chunks. And if you look, you definitely can find ways of doing that. And there's two reasons for this. One is it gives developers the ability to check something off and say, yesterday I completed this thing. And instead of, the other aspect of it is also, if you give someone too much, too big of a bite to chew, they don't know where to start on it at times. So definitely try to break things down as much as possible. Also try to, as much as possible, encourage a good work-life balance. While I can initially be productive, working lots of hours can be inefficient with increased stress, mistakes, bugs, things are missed. And it's really not sustainable in the long term. Another thing to do is make sure that everyone knows why they are doing something. You don't have to be, sometimes it's obvious, the why, you know, why am I building this content type? That's kind of an obvious thing. But sometimes if you hear someone say, well, why am I doing this? That's a sign that that person is ready to be demotivated, that they're looking for a reason to lose their motivation to work on that project. So it's good to have a conversation and explain why or how what that developer is doing fits into the larger picture. And you could also tease out maybe better ways of approaching something. Maybe the why am I doing this is actually a way for a developer to say, I could do it this other way and it would be better. So you might have to have some conversations and figure out, you know, make sure that everyone knows how their piece fits into the overall picture. And lastly for this, I just want to, you know, just a nice reminder, developers aren't just resources, we're people too. So check in with developers and make sure that they're happy on the project. You know, sometimes what we do isn't innovative and exciting, sometimes it's just, you know, to just be totally honest, sometimes we're just building a website, you know, but just make sure that developers are, they're engaged and they're happy on the project and talk with developers about things that aren't the project. You know, get to know them, build a rapport that helps build the team morale, the camaraderie of the team, of the project team. And that can have great payoffs maybe when a project goes sideways and people have to work a little more than they'd like. So, you know, takeaways for this would be, you know, help developers be productive as much as possible while maintaining good balance in their life, helping them maintain balance in their lives. And, you know, make sure developers know how what they're doing advances the project, it advances the larger goals for the organization and let them know that their work is meaningful in many ways. So here's the kind of the last section for this presentation. And this is me as a project manager and as a lead at HS2 and as a practice leader at other organizations, some things that I've seen and want to describe for you about how project managers can help with efficiency. And most of these are probably review for the more astute project managers in the group, especially since I've heard a lot of this information in other sessions at this con. So we'll try to cover these pretty quick. One is don't allow a site build to start too soon. Sometimes I know there's a lot of pressure, particularly when timelines and deadlines are involved, to start building before scope and requirements are fully locked down. Pushback against this as much as possible, it helps avoid rework and unscoped work and having to tear things down and build them again in a different way. And also if you need some leverage to get sign off on something or to get some resources, this is kind of like your last carrot to say, okay, we're not gonna build until we get this thing from you. So that's one item. Next is some of us developers are a little ambitious at times, so you might wanna try to wrangle them in a little bit. Developers can get really excited about wanting to try new things or new approaches or use a new technology. And at times that's really good. It's really good to encourage innovation but on some projects with tight timelines or smaller budgets that may not be in the cards. So staying in the course may be beneficial in that case. And also tease out when developers are having problems. You standups and status meetings to ask questions about do you need any help to complete this task? Do you have all the information that you need? And just ask point blank, are you spending your wheels on this? Are you stuck in that decision paralysis? Do you need to talk with another developer to work through some issues related to a technical approach? Also find out if they're getting sideswiped by other people within the organization for doing either working on another project or doing a business proposal or something like that. And definitely, and I think this is a common thread for this con in the project management track is have transparency with the whole team. Don't shield developers. Me personally, I don't like being shielded from the numbers. I wanna know how the project is going. Number of the velocity of the completion or how we're working against the budget. I find that information really helpful for me. And it helps as a developer me know if I need to work a little quicker, to maybe find ways to shave some time off of some tickets. So that's very helpful. And it keeps everyone abreast of the latest information, how the client is feeling. And I think last for this would be let developers show off their own work. Not all developers wanna be behind the scenes. Some do, and that's okay. Me personally, I like having that great one-on-one interaction with the client. So when you're demoing something, let the developer that built the thing do the demo for the client or the stakeholder. It builds ownership. At the beginning of this presentation we talked about you want people that take ownership. This is a great way to instill ownership. You're gonna be showing the client this thing that you built, this page that you built, this module that you built. So it gives the developer pride to show that off. Gives them ownership to make sure that that is done as well as possible. And it helps build rapport with the client. Especially if the stakeholders that you're dealing with are other IT people, it can really spur some great conversations. And it can even spur discussions about new work to be done in a future phase. So for the project managers, look at the project management process and see how you could help increase efficiency when dealing with Drupal projects. And also work with the developers, help them become more efficient and so far as you can. And help them elevate their craft. And finally, kind of the takeaways, hopefully for you in this presentation is know where your team stands, currently related to skills and experience. Determine some next steps for the Drupal practice to help it increase efficiency. And implement those changes into the Drupal process and the project management process. Implement changes that do facilitate better efficiency so that you as a team can be more productive. And with that one thing, two housekeeping things, you may have heard there are some contributions prints tomorrow. You don't have to be a developer to contribute. If you're not technical with Drupal, you can help write documentation or things like that. And I'd really like some feedback on this presentation. Hopefully you learned one or two little nuggets that you can take back to your home base. On the screen here is the link to the survey. And finally, thank you. I appreciate your time. And if you have any questions or if you have any information to share that may help others in the room, there's a microphone over here and we'll go from there. Sure. Yeah, the question is what tools do we use to help facilitate collaboration? At HS2 solutions, we're in on the Atlassian Suite, so we use JIRA, Confluence. Those are the keys, the two biggest ones that we use for collaboration and task management. We do include the clients on those and they don't have access to every facet. They can get reports. They can see the current sprint, the swim lanes on the current sprint. We use a command board for that. But we do include them on that. And typically, we have a few points of contact that have access to that on the client side. Everyone on the team at HS2 has access, but maybe one or two key people like a project manager on that side or a key stakeholder on that side has access. I'll just repeat it. Okay, the question was when someone has bench time between projects, how do you keep them motivated and not have some large-scale internal investment on things? At HS2, when someone does have, we call it bench time. We have a project board that's internal that is improvements to our base installation or to our development environment. And we'll try to put people to do things on that. It could be like add some scaffolding for creating this type of page or that type of page. So just little things that can be bite-sized so that if someone only has a day or two of downtime between one project moving on to another one, there are something that they can do. And you mentioned doing research, going back to that. Definitely the investment in the continued growth, have them take a course or take a class. But the flip side is we'll pay for you to take that course, but you're gonna do an info-share with the group about what you learned. And that can be helpful as well because you do have that actual cost of someone not being billable, but at least you can get some payback for the entire group by learning what they do. Is that helpful? Okay, great. Yes? Yeah, that can be a challenge, especially for the rock stars that are like wanted on every project. I'm sorry? Oh, the question is how do you make sure that developers have that time for their own investment in growing their knowledge and experience? And it can be a challenge. Again, like when you have the rock star developers that every project manager wants on that project, on their project. And you have to be regimented and say, okay, one day a month, the equivalent of one day a month or two days a month, we're setting aside for you to invest in yourself, to do professional development. And that's one good way. And we also, we do hackathons and other kind of lunch and learns. We call them where everyone gets lunch and tries to learn something over lunch. So there are definitely opportunities. You just have to, for some people, you have to be creative and be very deliberate about how you do that for them so that they do have that opportunity to do it. Yes? Mm-hmm. Yeah, to answer the first question, no, I can't share it. But a guide that I will give you is look at the AQUIA certification tests. They have study guides. That's a good guide mark to use for creating that. And we did a couple of different things. One is the Drupal Practice Lead at HS2 evaluated everybody. I'm not the Drupal Practice Lead at HS2. And then we also had everyone evaluate themselves. That's good reflective time for a developer to sit back and acknowledge where their strengths are. And you might find areas that someone says, oh, I know a lot about this thing, but they've never been asked or they never spoke up. So that's one good way. And based on that, we kind of did some trends and said, okay, we're kind of light in this area or that area. And that gives us a good place to focus and effort. So then when someone does have some bench time, a day or two of bench time, we say, why don't you do a little research on the new workflow initiative or the new media that's coming out so that we know we have someone who has research and has hands-on experience with it, even in a sandbox, and someone that can help elevate everyone's knowledge on that. And I think there was another question? Yeah, kind of. Unfortunately, forecasting and pipelines are out of my realm of experience, so I don't think I could provide a meaningful answer for you for that. That would be the Practice Lead at HS2 and other Practice Leads within our company. They work on that. Mm-hmm. We have done something very similar. We have productized some of our work. We keep it outside of the installation profile, but we have a few things, a few tricks up our sleeves as far as some layout management and that that we've productized so that when a client has something that has a desire to have something that fits what we do or what we have that product for, we can use that as and say, for X dollars, this is what you get, and then we'll build on that and customize it for you. That is, speaking of efficiency, that's ridiculously efficient because we sell it for a price and we just turn it on and then configure it and customize it for them. Mm-hmm. Yes, yeah, we haven't gone the full distro, the full-fledged distro route just because sometimes, you know, sites kind of diverge and go off in their own little ways that don't fit nicely with the distro and we don't want to have problems with that down the road if we need to build in, you know, if we need to do some updates or something like that. Yeah, it's flexible enough for what we do. Yeah, we got it. Yeah, thanks for the great presentation. Two questions related to kind of just very practical communications. What's the best intervention tactic when someone says that we'll fix it in QA or UAT? Do you throw like a pencil at the person or do you say that let's reconsider or post that? I would say, you know, oh, we'll fix that in QA. No, we won't, we'll fix that now. And, you know, just being direct and maybe explain, you know, kind of how I described, if we let this bug linger, it can cause more problems and just really explain the why for that. And yeah, it can be hard to shove a bug ticket into a really tight sprint, but it's something that needs to be done for the overall health of the project. Okay, and this probably goes also to the explaining the why, but you mentioned that if there is kind of demands and pressure in certain situations, you try to push back, but I was just thinking, how do you do that while still keeping the stakeholders happy? That's something for the project managers to manage and not, I will happily punt to the group here if you have any tips or tricks on that. Pushing back on pressure for starting a build with a tight deadline and keeping the client happy at the same time. Thank you. Organize more efficiently, so these things work, we would want the developer only for support, but if we get them operated, we will use one day at a week, so how do you do that? It's a balancing act, it's hard. You know, you can go and say, okay, developer, maybe junior developer, we're putting you on maintenance until, you know, you build up some skills, but then that can be, kind of feel like pigeonholing them or siloing them into that, and that definitely can be demotivating. I've experienced that with some other developers that I've worked with in other organizations. You know, I think time boxing for maintenance tasks is good. You mean, obviously, yeah, yeah, number of hours over the course of a sprint, you know, even on maintenance, we try to do two-week iterations and say, you know, obviously if your site crashes or if there's a critical bug, we'll fix it as soon as we can, but you know, if we have this backlog of things that we want, that we know you want to get done, let's pick three things that we'll do, and if something else more important comes in, you let us know and we'll get, you know, we'll prioritize that above the others, but otherwise, within the next two weeks, we'll have these three things done, and we try to do it that way, and if you bake in kind of the assumption that, yes, Mr. Client, Ms. Client, you have X number of hours with us per month, you know, and they're use it or lose it, then the client will be motivated to make sure that they're staying on top of requests and new features that they want, and, mm-hmm, mm-hmm. That way to get that across to people and make sure that they've got awareness, is there, you know, do you document it or visualize it or anything? Yeah, good documentation is definitely helpful. We don't have any kind of visuals on technical debt. We probably should, just to keep it top of mind when we do have some bench time or, you know, a client does have some time with us that they want to use, and they don't know exactly what for, we can help try to reduce some of that debt, but I don't know that I have anything really specific that I can offer for you on that. I think it's a common problem everyone has, and no one knows how to quite slice that up yet. Yeah, yeah, a nice tote board of technical debt would be good to see that every day when you walk in. All right, well, we're at time right now, so again, thank you everyone for coming. I'll hang around up here if you have any questions. Thank you. Oh, yeah, I want to listen in on this.