 So thanks, everybody, for joining us. This is specifically to talk about staffing and capacity building, facing our specific challenge of talent starvation. So just to get a sense while we're resolving some technical, the standard technical issues, standard issue. How many people here are actually currently attempting to hire the majority of the room, in fact? Are there people here who are, this isn't a matchmaking question, looking for work? So there usually are a few people who show up also looking for work. Our hope is to make this presentation rather quick so that we can get into talking about specific use cases. But maybe we can start to get a little bit of a sense of kind of the specific need. How many people are hiring for very small shots, let's say five people or small, a few people? How many between, let's say, a break off of 30 down to five? And how many for larger than 30, anybody over, say, 200? All right, cool. There have definitely been some conversations with some very, very large shops. And I think that that's a different challenge. And we're very pleased to be talking about the smaller shops, I think, in this time around. So in any case, since we're in a little bit different situation, do you mind just kind of hitting the slides forward? Cool. And I can also, actually, I'll sit down next to you. We can make things easier like that. Is it all right? I assume it's all right. Everybody can see if we're sitting instead of standing. So in any case, I'm Kay Van Wolkenberg, principal of Oensourcing, which is a training company in Boston. And I've been doing Drupal since 2007. And prior to that, I was doing software development, mostly for the web, and also for exhibit displays since 1998, and a trainer since 1990. And I'm Jesse Day. And I've been working with Kay at Oensourcing. And I've been involved in Drupal since 2010. I'm a developer and a trainer. And prior to that, I worked as a teaching assistant and tutor. And so the education and training aspect of what you can do with Drupal is something that interests me a lot. Cool. And of course, there's a third personality who features prominently in our title. And that is Maslow. I'm sure everybody's very familiar with this psychologist. But just in case, because this concept is pretty key to what we're talking about, Maslow is famous for his hierarchy of needs. And his notion was that human beings are capable of accomplishing great things and having great satisfaction. But in order to experience these things that he actually termed as peak moments, you had to have a number of things in place that were basic requirements. And these range from very fundamental things, breathing, water through some still relatively concrete things to things like family, sexual intimacy all the way up to things that are quite hard to truly get concrete about in our heads, creativity, spontaneity, and things like that. So interestingly, the notion of Drupal is often also described in terms of a peak. But more often, that peak has kind of a treacherous side to it, where people picture it with piles of corpses accumulating at the bottom and things getting worse and worse for Drupal teams. I'm sure you're all familiar with the image that's gone around the internet of actually a bulldozer pushing corpses off the edge that came up again in the Drupal ladder presentation just a few moments ago. I don't know that that image of Drupal continues to be a particularly useful one for us to propagate in the community. I think that it was probably true, certainly leading up to 2007 from the war stories that I heard. Around 2007 when I started, Drupal 5 came out. And I got the sense that people felt that we were turning something of a corner. And I would say by now, it feels very much like we've turned a corner. And I think that that corner is that now we have a framework that we can rely on. There was a bit of a debate a couple of years ago. Is Drupal a CMS? Is Drupal a framework? And I think it's fair to say that it's both. And that framework basically means that we, as developers, can rely an awful lot on a structure provided by software and, importantly, a structure provided by the community that helps us avoid these harrowing experiences that people describe. And I imagine there are some people in the room who perhaps feel that this precipice is still very much a threat, still very much in place for what it's worth just to illustrate how many people, or maybe this isn't even a fair question, imagine how many people would raise their hands if we said how many people have actually stepped through the bootstrap process, for example. Very fundamental thing happens every time a page is loaded on Drupal, at least ostensibly. Step through the bootstrap process even for the most simple page. I can't imagine just in the conversation that I've had in the community, there being more than, say, maybe one or two. So maybe those brave souls would like to raise their hands. We rely on that, and we don't need to worry about it. And in fact, unless we've got some very dire testing need, it doesn't happen on a project. We don't step through the bootstrap process. So I know that there are people who do it, and that it's a useful thing to continue working on. But if we start talking about this hierarchy of needs, where can we actually start drawing a point at which people can feel successful? Back in 2007, this famous learning curve was put out. And it's certainly worth noting, I think the bottom of the screen might actually be cut off, but it's certainly worth noting that you did an awful lot of learning before you could work. In fact, only the very top two lines represent when people could theoretically be productive and work as a Drupal consultant or in a Drupal shop. And then the next step up was IMCHX or Unconed. So I think that that, we can all agree, has changed significantly. And the thing that we'd like to pause it today from personal experience, from having surveyed a number of shops in the Drupal community, and having trained new users, we can now say that you can successfully hire people who haven't even completed the bottom item on this and expect them to be productive within weeks. That this isn't, I can't quite scroll. Is there a scroll down so that we can get? So the bottom in any case is that you can install Drupal. And we can get into some very specific cases if that sounds a little too incredible for people. There have been some great successes with people coming up. All right, so what does it mean, this thing that I feel, I haven't heard a lot of confirmation elsewhere necessarily yet, but I feel pretty strongly that the fact that we have this framework provided by the community and provided by the software really does constitute a major advantage over at least a few years ago, now much of the functionality that we have access to and much of the functionality that goes into a large range of sites is actually plug and play. In fact, there's an entire class, group, professional niche in Drupal that works entirely on 100% plug and play technology. They click together websites. It's been the dream in Drupal for a long time. And there is a thriving group of developers who do that. Is it, were you able to pull up the Drupal Gardens? Show of faces. Yeah, cool, so we'll switch over. Do we have the URL as well to share? Yeah, sampler.drupalgardens.com. You can see some pretty impressive sites that have been clicked together. Now, this is worth bearing in mind because we think that this approach of focusing on click-together websites is a good starting point for new members of the community. This isn't a new idea that's been put around for quite a while. Is it easy to go back to the, cool, right? So that's the upside. You have all this functionality that's basically configuration. On the downside of this existence of a framework, this also means that you could look for people with web development experience that spans a decade, and they're still going to need training. And that's just the raw truth of it. And I'm sure a number of other Drupal shops here received quite a large range of projects that have come from talented PHP developers. And they're no longer viable as Drupal project. One example not too long ago, we received a project where a talented group of PHP developers had created some quite elegant code for including menus and had put them directly into Garland templates. Fortunately, that was a relatively simple fix. We started with a Zen-based theme and re-themed their site for them, and they were good to go. But while they had this situation, it of course meant that while with Drupal anyone who has permissions can change menu items, in that particular case only the developers could. And they had a bit of a blocker also when they wanted to do certain types of upgrades. So this very experienced team had taken that project down a somewhat unviable path. And I was expecting gasps from the awful scene that's depicted of people falling off the Matterhorn. In fact, the shocking thing here is anybody who's familiar with the doc route in Drupal.org. Some people are smiling, thank you. It's actually supposed to be kind of fun. So people who are familiar with the doc route in Drupal will recognize immediately that there are a couple of filenames in here that are very unfamiliar and probably mean that the team who worked on this site hacked core. If people aren't familiar with this term hacked core, it's a very bad thing that has horrible consequences, including the death of kittens. So this was a quick clue when this was actually part of a training project, the team that inherited this site found that they weren't successful in doing upgrades. So they felt they needed to learn more about Drupal in order to do a number of security updates that needed to happen in fairly short order. And every time they did it, the site fell apart. And so the pre-training review of what they had to work with, of course, revealed that this wasn't a Drupal challenge. We could still train on the items that they wanted to train on. But the real challenge was actually going to be discovering how core had been hacked and why, and then implementing the features that they had through these non-standard coding practices, through instead standard coding practices. So whether or not you buy the idea that starting with click through site building is actually useful for your shop, I can certainly tell you that those two instances I just cited, which are very fresh instances in our mind, would have been completely avoided, had those two groups spent time, perhaps on Drupal Gardens, for example, in a walled environment, figuring out how things happen in Drupal and not having that option of turning to code. One of the fun things about being involved with Drupal earlier than I was, from what I can tell, is there was a sense of adventure. And I think the early adopters of Drupal were real adventurers. And I think that when you're trying to hire for small shops, you continue to need a certain amount of that adventurousness, tempered with a sense of these paths have been well-carved, and it's best probably to pull out the roadmap and figure out how best to do them. So now here's the problem that goes along with it. The roadmap is not particularly well written out. And there's a ton of stuff you have to know in order to avoid this. So part of what we'd like to talk about today is the plan that we've hammered out and implemented and tested that has been working quite well for getting new people from outside the community up to speed in short order. And we'd also like to talk about some of the challenges around getting the existing developers that you have also to continue with their learning and growing their skill, especially with rather dramatic event coming up with, of course, the release of Drupal 8. So I wouldn't claim with Drupal 8 at the point it is in its development right now that we have a good, clear idea of exactly what kind of training has to take place. But I think that this format is flexible enough that there will be some applicable items. And we'd love to turn this into a conversation, like I said, in a pretty short order. So we're going to talk a little bit, like K was saying, talk a little bit about how you get people new to Drupal kind of up to speed. This right here is actually a instructions for climbing the Matterhorn. And it's really not that useful. But we see people trying to instruct new Drupal users in a similar way. We actually talked with several Drupal shops before doing this presentation and tried to get a feel of how they brought in new developers. And some of them said, well, yeah, we hired a front-end person and we expected that they were going to be able to learn the back end. But when pressed a little bit, what they told us was essentially, obviously they provided them support. But we gave them a book and we were kind of hopeful that they were going to figure it out. And in reality, that's just not, you really need to package your training in a more structured way. So definitely instructions, support, they're helpful. But they will be best when combined with a few other more structured items. So things like giving your new trainees simple tasks and tasks that require research and then always coming back and reviewing that. And so really, if we look at these, something like simple tasks, this can be something as simple as having them run security updates. You can have them run security updates a few times. They get into the flow of how they actually have to work with the team. And they kind of start to understand, they made during security updates understand what it is, why you don't hack core. You try to do a security update and maybe you lose a bunch of important functionality. Of course, to go along with that, you can't let your high-rees get bored, of course. So tasks that require research are a great way to make sure that they're learning, that they're involved, that they're interested in the project. I know when I was just starting out, Kay gave me a task to build views with relationships. And at the time, that was a bit of a stretch. But it was something that I figured out. I'm sure Kay could have done it much quicker than I could have. But he let me work with it and roll with it. And in the end, it's a skill that I've learned and that Kay can now delegate. So it's always coming back to not only your developer becoming a better Drupalist, but you also being able to spend your time in a more productive manner. And of course, code review, if you can't, you need to be able to review what people are creating, review the functionality that they're making, and really just ensure that they are finding and creating functionality with best practices. So with that in mind, we have a bit of a sample learning path. And these are things that we think all Drupal, all people new to Drupal need to know. It's not necessarily just somebody that has no technical experience. Somebody who is a PHP developer coming into Drupal will need to know these things too. If a PHP developer doesn't understand the content system, the navigation system, how users work, then you're probably going to end up with someone who really doesn't understand Drupal. So just the configuration and building sites through the admin UI is a really important first step for bringing somebody onto your team. In addition, I know everybody here is interested in being involved in the Drupal community. And one of the reasons is that we can rely on each other for things like bug testing and just future-proofing our site and innovating. And if we don't teach our developers to rely on the community, then we're going to end up with a Drupal site that may or may not be, you know, be upgradeable in the future. I know one of the things that Kay and I talked about a lot and that we've already touched on a couple of times is upgrade paths. But, you know, if you're writing your code in a way that doesn't provide a reasonable upgrade path, you're going to be in trouble. And then, of course, the last thing, being extending Drupal to reuse content, just in general leveraging contributed modules, contributed themes. You know, Kay talked about the Garland theme being hacked earlier. You know, they could have done their development using a sub-theme of Zen, but, you know, it wasn't something that they understood. So it's not really a knock on them as developers. It's just bringing people into Drupal and showing them what they can do pretty much just through configuration. So we actually have a few sites that we know are built through configuration. This is from thetop.org. It is a site that was built by own sourcing. And, you know, it's got everything that the organization wanted out of a site. And it was built completely through contributed modules. We can see content being reused. We can see users. We have users here being located on the map. And, you know, we have views. This is a, you know, to us very simple, but something that you would not want to attempt to write yourself. And, you know, so understanding the, understanding, leveraging what comes from the community is very important. We also, this is a site that was actually built by the AquaEU program. And I don't remember if Kay actually mentioned it or not. But he was the co-director of the AquaEU program, which was a program to train people from outside of Drupal and bring them into the AquaEU team. And they started on this site when they were one week into their training. They have varying amounts of technical expertise. But this site was built with contributed modules, CSS, and a little bit of jQuery. And I think it came out really well, you know, for any site, not just for a site built by people new to Drupal. So it's really just a testament to the things that you can do with Drupal. And yeah, so these are kind of the, a few of the things that I just talked about feed into these roles that we normally see in a Drupal team. And basically what I talked about were those first three roles, a site builder, a basic themeer, and a site architect. And those are the roles that we believe you can bring in Drupal people and, or sorry, bring in people from outside of the community and really have them contribute right away. Possibly a site architect needs some more experience. But between basic themeers and site builders, they'll be contributing to your Drupal projects within weeks. So there are a couple of other more advanced roles on here as well. And these, I don't know how many people are actually familiar with these roles, but they've been fairly well tested within the Drupal community. They're a little bit different from the way project teams were structured, you know, or probably continue to be structured without Drupal. But site builder, as Jesse was saying, focuses mainly on configuration. A basic themeer generally gets the work done using configuration, a little bit of CSS, in some cases HTML actually, relatively infrequently for really basic theming. And then the site architect helps determine how things are going to be built. That's quite common across different projects. Advanced themeer and module developer are probably self-explanatory enough. But so how do you deal with the more advanced roles in that case? Let's say that these people are already very familiar with the first three items that we've identified in our hierarchy of needs. And then they are like actually a lot of projects looking for the next level of skills. I'm imagining that if you have experienced folks on your team, they are already working with what Addison Berry likes to call altercoding. Oh, I'm sorry, I'm misattributing that. That's actually WebChick who was talking about altercoding and how at a certain point you get your site pretty much to where you want it to be and then for the last say 10% you actually need to make alterations to the code. And of course Drupal has quite a number of ways of overriding and altering things that doesn't end up changing core code and doesn't ruin your upgrade path. Pre-process functions and alter hooks are certainly two that are worth talking about. And then yet another level up, if you are not finding the types of modules that you need, then obviously somebody who can work with existing APIs to deal with high traffic situations, to deal with integrations and then some of the larger issues that, for example, the large-scale Drupal working group is working on. You know, these are things that are fairly logical to aspire to if your types of projects lead in that direction and helping to move your more advanced team members in those directions is certainly something we'd like to discuss as well. Of course at a certain point not all the necessary APIs have already been written or underway and not all of the problems that we as a Drupal community will face have been identified. So certainly talking about how one innovates even beyond that is worthwhile. All right. So what does it mean then to set out to actually hire for these roles? If we're going with the assumption that the talent that has, let's say, five, six years of Drupal experience is pretty scarce, pretty hard to find and we're going with this idea that actually we need to reach outside of our community in fact quite energetically and bring people in. Who are those people? What should we do? What kinds of projects can we put them on and how do we help them once we get them in so they're not facing that cliff that Jesse was talking about earlier with a couple of sparse instructions about hidden handles and a ledge you can stand on. One of the important things is to recognize that probably some part of all of your projects actually has a good fit for junior developers. Let's just refer to them for now as junior developers, people who are coming in from outside of the Drupal community. So here are some earmarks of a project. They have a clearly defined engineering task and what we mean by that is it's appropriate to get them involved once they can basically take... How many people here actually use JIRA or some similar tasking software? So a good number of people actually use JIRA. The notion is that once things get into JIRA generally the best practice is that they are actionable tasks that it's no longer at the point of discovering what for example a user story is going to be. We have a user story and we know that we have some tasks to break out to complete those. That's a very different situation from saying we have this audience and we have this message and how are we going to put those two together. So clearly defined engineering tasks broken out into actual actionable tasks and the opportunity to have the learner participate in the team without actually being part of the velocity to deliver that project. So in other words they're taking some of the attention away from the people who are giving them assistance but they're also putting their effort in to relieve some of the tasks. Ideally those things should balance out obviously at the very beginning they're probably going to be needing more attention than they're giving back and toward the end they're going to surpass that but ultimately on a week by week basis you should be able to set things up to balance those out. If you've got such an advanced project that that balance isn't conceivable it's probably not a good fit for someone coming in from the outside. Potentially. That seems to be a real minority of cases. And then team member that actually is a bit cryptic. The opportunity for the learner actually to become a team member is another good sign of a project characteristic. Now in some cases you can't actually involve them in these projects for let's say a couple of weeks to three weeks. Well they get used to the team, used to the tools and used to some of the basic concepts of Drupal and it's certainly reasonable to look two or three weeks out to figure out what is going to be coming up for these people. So what are some of the characteristics that make for good learners? In the survey and I was actually as part of the project, the pilot for AquaEU I was part of the hiring process as well and the characteristics that we identified ended up being quite true through that project. The first thing that seemed the first extinguisher seems to be is the candidate actually a good cultural fit and the culture of your company obviously can be defined in a million different ways but making sure that there is an opportunity for some chemistry for positive experiences in both directions that seemed to be almost as important as any kind of technical experience they were bringing with them. Self-directed learners that the person actually is able to let's say even demonstrate that they've taught themselves a number of things. We're not going to turn them loose entirely on their own but this ability to identify what they need to learn, what they want to learn and then pursue it and then find and use the resources that they need. This is probably the thing that most distinguishes this approach to training to the typical thing where you call a training company up and you say I want two weeks of training from my staff because at that point the training company will come to your office with a lesson after lesson planned out and the time filled up with people sitting in a group like this listening. So this is a very very different approach where you're actually asking people to take responsibility for the things that they are going to learn for the things that you need them to learn and that they want to learn. They need to be self-directed learners. And then they also, and this is perhaps the thing that tempers the self-directed learner part it's good to get indications that they actually know when they've hit a blocker and they can ask for help so that they can take, let's say, they can consider whether a problem is challenging or relatively minor. For a minor one they spend 15 minutes looking around and try to figure out what's going to be a fruitful path and then they go and ask someone for a little bit of a redirect and for a more challenging one maybe they spend half a day but they certainly don't spend, say, three days on a problem that they could have gotten good direction on. And then the final item is that they're responsive to coaching and I think that when you're interviewing people you can get a pretty good sense of these four items and they tended to be quite good guides and we can get into in the discussion some of the specific examples that we have. So once you've got a good project, at least on the horizon and a good crop of pyres, then what do you do with them? Well, obviously they're going to need some of the instruction Jesse broke out the four learning modes, they're going to need some of the instruction. If you haven't used Git before, you can give them some pretty simple instruction. I think we came up with six Git commands that anybody can learn in a very short session and then they can start implementing on these repetitive tasks that Jesse was describing. So they've acquired a little bit of information and they do a whole bunch of things. Those specific things may just be fairly rote but that kind of rhythm of using Git, working with the team, understanding what the tickets are about, responding on tickets, getting them into that flow, give them a bunch of attainable tasks that they can do that on and have a mentor who's actually ready to pick what those tasks are in the project, assign them, serve to get them unblocked and review their work as they're going along. So identifying people within your team who are able to communicate that way, who are able to identify tasks and assign them appropriately that's not tended to be a big challenge for development teams. They generally have people who are able to do that who also have experience with the types of tasks that need to be done. So identifying those mentors and pairing them with learners on the AquaEU project. We did it relatively arbitrarily. We didn't spend a lot of time thinking about which mentor was going to be paired with which of the eight people who would basically meet for 15 minutes, walk out with a mentor pairing and for the most part they went quite well. There's a lot of will on either side to make the pairing work. So true both for new people coming in from outside of the community and for people within your team, the community itself actually provides a fair number of opportunities for mentorship. I don't know how many people attended Gabor Hochi's session on contributing to core, but he talks a fair amount about good ways of learning through getting involved in the issue queue and providing value to someone, a core maintainer, in his specific discussion, providing value by being able to get tasks done at the same time you're receiving value from one of the top minds in Drupal or the other people who are assembled around this at least, sharing their thoughts on the best solutions on the code that you've submitted and things like that. Obviously learning opportunities like conferences and meetups are really big. I think conferences are probably one of the best ways for sharing information about best practices. So I think that's a great investment, especially in your more senior people to send them to Drupal Cons and Drupal Cams. Hosting them in your office is a great way of drawing potential talent and giving to the community. So there are quite a number of ways. We also list a few URLs, Drupaladder.org, great learning resource that Jesse and I have both been involved with and the core mentoring hours and of course the Drupal 8 community initiatives. So these slides have all been saved. The URLs are there on the node for the session. So if you don't mind, it'd be great to have your feedback. We've given a shortened URL here, but it's basically going back to the session node and please go and let us know what you think. But very importantly at this point, like I said, we wanted to keep this short so that we could get into more specific stuff. So we've got about 20 minutes. And please use the microphone. These are actually being reported, so it's great to share that with a remote audience as well. We've had a slide about making other developers issue queues, introducing, that's really great to do that. You cannot force them to do what I thought was an exception. So, you know, that's a great question that comes up pretty often. How do you motivate people? One of the things that we didn't talk quite as much about and I had actually meant to, but we were, I think, pushing a little bit of time, was one of the tools that we use is a learning plan, an individualized learning plan. And usually that's administered by either someone who's very senior in your firm or by somebody who's outside your firm. And that learning plan can be as loose as, wow, I'd really like to know more about some, you know, relatively like a year out type goal. I'd really like to stretch myself about Backbone.js or about, you know, any number of exciting things that are happening in the community. If they're not motivated actually to have those types of goals, perhaps, you know, setting shorter goals and trying to cultivate that motivation would be a good part-way step. But just to, let's just assume that whether they're motivated because their performance bonuses are tied to them actually acquiring that information or they're just hungry for knowledge, that tends to be the case a lot I think in the community at large, I think that that starts to provide, I think often motivation is less about the impulse or will of the person and often it's actually more about achievability, actually seeing steps for getting to a particular spot and seeing the excitement that happens, whether it's a bonus check or actually having skills that are exciting to them. You know, laying out these steps, working out with these steps are going to be how they're going to be enabled and removing blockers I think is the main way. You know, maybe it's my infectious enthusiasm. I've talked to a lot of people who don't feel motivated and by the end of the conversation they're generally talking about what's going to be exciting to them. Does that touch on your question or did you just skirt it? Yes. Do they like where they are? Yes, and then that becomes a hurdle for your company. Is there an incentive? Is there enough reason to move out of a place that might be comfortable? Is that part of the problem or do you think that the problem lies elsewhere? Two types of people. One actually making one. Yes, I think that that individual coaching that has been the thing that the tool that we pulled out of the toolbox in the past in those situations and the individual coaching when it's me who's doing it basically the question that I'm asking. I'm asking all kinds of things around interest and activities waiting to see some kind of spark. So a recent conversation that I had was with someone who was quite excited by the English language and by writing and by finding new ways of communicating with people. And so moving tasks that that person had available in that direction actually ended up being the main motivator and led to a place for room for growth. So I think it's that conversation finding out why that person is there. If it's true contentment then it's probably awfully hard to find an incentive not to stay there. But if there's something that is like a better thing that we can reach for. I'm still not sure that I'm satisfying your question but I'm happy to talk to you more about it afterward. I mean it's certainly something that we've come across. Yeah, another question back. Would you mind using the mic just so that people can know? Oh, it's not working? How about if we pass this around then? Is that better? Yeah, I really enjoyed the presentation and already kind of doing a lot of that in our recruiting. But on a completely different note what do you think Drupal 8 and the symphony stuff is going to have an impact on everything you've just talked about? So it sounds like we've already said a fair amount that was obvious. So unfortunately with that still all unfolding I think it's a little hard to say anything too concrete. One of the plans that we have is actually around local meetup and actually finding people in the community who are interested in first cracking what this can mean for us. Obviously there are things already available. We can already work with the symphony framework and Drupal 8. I haven't confirmed this personally but I believe that there have been recent releases and I'm sure there are people in the room who can actually confirm this. Recent releases that have components of symphony already integrated. Is anybody able to confirm that? So if that's the case and I believe it is then you can already start. One good resource for that is actually the Drupal Ladder. Drupal Ladder.org. Install Drupal 8. Start looking at the issue queues. It will give a very good sense of where things stand with integration what challenges are coming up on the one hand. On the other hand it will help start getting insights into what it's really going to mean to adopt symphony. So we'll continue to work on that question and that's the first direction that we plan on taking. Well first two directions. I really enjoyed your talk and appreciated a lot of the specifics of different approaches you can take to bringing in people who are not necessarily Drupal. One thing you didn't mention though, you mentioned training but kind of you bring in a trainer and they're going to sort of do this very generic approach but there is also the other option of there are trainers, I'm one of them, K and I talked in Chicago a lot about this, who will come in and do custom training to projects. So for example, especially if you're a small company and your existing developers really don't have the time to do this mentorship but you need to bring on new people, you can find trainers who will sort of work with you to provide that customized training, that kind of mentorship even if you don't personally have, your existing team doesn't have that time. But other than that, I have really excellent ideas. Point taken. Boy, that speaker must be dangerous. Okay, let's try from over here. I just want to ask, it's really to the floor, there's so many people here who are recruiting like we are. Have you all given up on local recruiting? Are you looking globally now? And if so, what sort of challenges when talking about mentoring do you get when you've got the team that are not in the same place? I suppose it's not really a specific question. Is anyone experiencing that? Well, and I wonder if it's, is that by a raise of hand? I imagine that a lot of people are feeling frustrated. I wonder if in part, if we can cobble another kind of raise your hand type question, does anybody suspect that the requirements perhaps in the ads that are going out in the local area seem like a barrier? I mean, we keep seeing these, the inspiration was Jesse saying, look at these, look at this long list of ads and people are looking for the entire lamp stack. You know, we want you to have it all. And C sharp. And, you know, so, you know, it's like, shoot, what do you do at that point? So, several people said, yeah, they think that that's part of it. So, the response for those who couldn't hear it, if I can paraphrase, the response was like IBM. IBM hires saying, we don't care what you know, we'll teach you what you need to know. Yeah, the motivation to grow as opposed to the money is really where the solution lies, hiring the people who are motivated to grow. Those who are motivated by the, oh, thank you. This feeds back into your first slide, which you just touched on and then moved on with actual sort of training and so on. But you're looking for people who are motivated by the top of the pyramid, not the middle or the bottom. Sure. It doesn't really matter what their skills are, what you're looking for other people who are motivated by self-actualization. Thanks for bringing that back around. Yeah, and to help the lady a little bit, I will say that the training of new people in your company should be a process on the long term and to solve the time problem for the older people through the company that might become mentors and help others becomes also a project management-related issue. So you should include this time in their time and give them a free window every day so they can have time to take care for those new people. So it becomes part of the project shadow, the project budget and everything else. So they create this free time for them to help others and train others. Yeah, that's a good point. And you recreate in a company, it's new. It's new there. He has many times to adapt. He needs time to learn new things. So because he needs a time, we have to take that time from others' time and give it to him to help. Yeah, I think that's a point worth emphasizing. It was really gratifying when working with the Aquia team that basically everybody in the Aquia office recognized that helping the new folks get up to speed was going to solve problems for them down the road. And I think the culture was ready and was geared in that direction. And the project management load that you're talking about, there were a couple of points. Perhaps we should break those out after so that people who want to go off to beer can do that. But there were a couple of key points where the project management load was particularly heavy to prepare for integrating people into the team and giving them real life tasks. And then after that beginning point, then the project management side of things was a bit more distributed, mostly by relying on mentors and by relying on people who owned a set of tasks and could involve the person who was learning in that set of tasks. So they still needed a little extra time. So that was balanced out by being able to hand things off. Drupal is famous for being self-organizing, so it's cool that Mike gets past. Something like Elance or something similar to that, ODesk. I personally don't have a specific recommendation. We've been focusing on getting talent and growing it, so we haven't been quite as focused on... I mean, Drupal Meetups, certainly, without a question, are great for building that kind of Rolodex. I don't know if you're talking about a larger scale than that. And then just working on projects, collaborating with other companies has led to us having resources beyond just the ones that we're growing. I don't know if that helps at all, but it's really been... For us, it's been Rolodex-driven. Does anybody else have a resource that they use? One thing I would say with that is some of the same sort of resources you would use outside of Drupal for looking for that kind of help, like Craigslist and the various... I can't remember the names of them right now, but the various job posting sites that are generalized. But one of the things you want to do there, going back to the point we just had a little bit ago, is you want to make sure that your advertisements are asking for what you actually need in a Drupal. One of the problems that we have is particularly companies who don't know anything about Drupal but want to hire Drupalers, they're asking for the wrong things. What they need is a site builder, someone who can click through and build a site, but they're asking for a module developer by saying, we need a Drupal developer who has amazing PHP skills. And that just frustrates everybody. So one of the things that's important, if you're looking for experience to Drupalers, is ask for what you actually need in the terms that are familiar to Drupal people so that they'll recognize, oh, they're not really asking for a module developer, they just need a site builder, or they need a themeer, because that will really help you connect to the people you're actually trying to hire. Yeah, that's a good point. I think we have the room for about three more minutes, so that's probably two questions worth.