Mike and Matt are joined by Lullabots Cathy Theys, Greg Dunlap, Cristina Chumillas, and Albert Hughes to talk about hiring people into different Drupal roles. 

This Episode's Guests

Greg Dunlap

Thumbnail
Greg has been involved with Drupal for 8+ years, specializing in configuration management and deployment issues.

Albert Hughes

Albert Hughes headshot
Albert Hughes is a technical project manager with over 10 years of experience managing, developing, and architecting enterprise-level web projects.
Transcript

Transcript

Matt Kleve:
For September 2nd, 2021, it's the Lullabot Podcast!
Matt Kleve:
Hey everybody it's the Lullabot Podcast, episode 254, I'm Matt Kleve, the senior developer at Lullabot, with me as always co-host of the show, senior front end developer, Mike Herchel, hey Mike?
Mike Herchel:
Hey, how are you doing, Matt?
Matt Kleve:
I'm doing great, we're going to get the band back together again, it looks like they took the summer off.
Mike Herchel:
Yeah, but we have an awesome band today.
Matt Kleve:
We do, we got Lullabots, strictly people who are employed by Lullabot on the podcast, talking about people.
Mike Herchel:
Yeah, we're talking about different roles, hiring for different Drupal roles. For example, content strategist, developer, designer, all that technical stuff. First up from Dulles, Virginia, support project manager Cathy Theyes, welcome, Cathy?
Cathy Theys:
Hello, glad to be back on the podcast, and talking about hiring.
Mike Herchel:
Yeah.
Matt Kleve:
Also joining us today from the scenic Monterey, California Coastal area, Lullabot's Director of Strategy, Greg Dunlap, hi, Greg?
Greg Dunlap:
Hey, hey?
Mike Herchel:
Also with us from scenic Barcelona, Spain, front end developer, Cristina Chumillas, from Catalonia.
Cristina Chumillas:
Hey there, thank you for remembering that.
Matt Kleve:
And one more person on the podcast to round us out, we have technical project manager, joining us from Memphis, Tennessee, Albert Hughes, hey, Albert?
Albert Hughes:
Hey, hey, I appreciate you all for having me on today.
Matt Kleve:
And relatively speaking within the group, you're the new guy, right?
Albert Hughes:
Yeah, this is actually my first time on the podcast, and the newest person on the call.
Matt Kleve:
Yeah, that's fun. Welcome, glad you're here.
Mike Herchel:
Albert actually gets the pleasure of project managing for me and Matt, on our client work here.
Matt Kleve:
You should be working on your tickets Mike.
Mike Herchel:
I would like to apologize for all the code that Matt writes.
Matt Kleve:
That would be deserving likely?
Albert Hughes:
Yeah, and it's an honor.
Matt Kleve:
So just to be clear, and I think we'll say this off the top Lullabot did just recently go through a round, where we hired a good number of people. We hired some front enders, we hired project managers, we've hired some folks in our content strategy department.
Matt Kleve:
We're still in progress hiring a couple of those positions, but we're currently not accepting new applications, just thought I'd point that out there. jobs.lullabot.com is a good spot on our website, to look to see-
Mike Herchel:
No, no, lullabot.com/jobs
Matt Kleve:
What the hell? Well, why is jobs there then?
Mike Herchel:
Well, we have jobs, but there's no job subdomain off of lullabot.com
Matt Kleve:
Go there, it totally works.
Mike Herchel:
Does it, does it redirect?
Matt Kleve:
I don't know.
Mike Herchel:
It does.
Matt Kleve:
So anyway, lullaby.com/jobs would be a good place to go and look, and that would give you more information about the kinds of positions we're currently have open, and would love for you to apply for. So I'm going to guess that hiring for a Drupal job is different now, than it was 15 years ago? That would be fair, about 10 years ago?
Cathy Theys:
Yeah, absolutely.
Greg Dunlap:
Was there even really a Drupal ecosystem to hire jobs for 15 years ago? I mean, Lullabot is just 15 years old as it stands right now, so I don't think that really existed.
Cristina Chumillas:
Well, maybe 15 not, but 10 years ago.
Albert Hughes:
Ten years.
Cristina Chumillas:
I could say there was a community, and it was completely different from the one that we are right now.
Greg Dunlap:
Yes.
Cristina Chumillas:
On a hiring perspective [inaudible 00:03:48].
Cathy Theys:
Yeah, I think in the past, if you wanted a Drupal developer, you might be able to hire one, but I think one of the things that's changed now, is we want to hire people to do the job, and if the job might have to do with Drupal. And one of the things that we're trying to figure out right now is, can we hire people with skills that they come with, and then teach them Drupal?
Cathy Theys:
Or do we need to hire people that already know Drupal, and expect them to already know things, and not learn as much on the job? I don't know if that's changed over the last 10 years, what do you think?
Albert Hughes:
I feel like 10 years ago there, there wasn't a content strategists, some of those jobs, it seems like that wasn't a Drupal type job. I think front end developer, back end developer, project manager, those roles seem like they've been around for a while. But it seems like recently, things more along the lines of content strategy, even some of the... I think, you had designer, but I think getting even more into the UX UI, getting that into titles, I think that seems like new ish into the Drupal ecosystem of jobs.
Albert Hughes:
And I don't know if that's also following trend of overall web development, and web jobs, period, and so I think with the Drupal, the ecosystem, it's interesting, because you have Drupal knowledge, and then you have these other jobs that apply into the web. So it's a interesting mix to get into the Drupal space, for a Drupal job, per se.
Matt Kleve:
So maybe, let's go down the list of different titles that Lullabot has. So Lullabot, for those listeners, we have what? About 60 yard people working for a company right now? We're one of the oldest Drupal development shops, we've been around for 15 ish years. So titles that I have written on my notes right here, we have both backend and front end developers, project managers, we have architects.
Matt Kleve:
I have on the list right here, site builders, but we don't have anyone that has a title of Site Builder. We have several different designers, we have content strategy roles, like content strategists, and we're in the process of finalizing some hiring for a content designer. And on top of that, we have things called lead engineers that we have here too.
Mike Herchel:
And technical architects.
Matt Kleve:
Yeah, and architects and technical architects.
Mike Herchel:
And of course, our admin roles.
Matt Kleve:
Yeah, yeah.
Mike Herchel:
HR, and accounting and bookkeeping, and invoicing, and all those kinds of things.
Cathy Theys:
One of the ones that I was thinking of Mike, talking about those was sales, because I think sales could also be like, "Do you know Drupal? If you don't know Drupal, do we need to teach it to you, so that you can do sales of Drupal, or if you already know Drupal, does that give you an advantage in sales?" I think a lot of this is, what roles do you need to know something about Drupal for, and how are we expecting people to acquire those Drupal knowledge skills? Is it on the job, or is it before they get hired?
Matt Kleve:
So what's the answer Cathy, you bring up a really interesting, hard question early on, is it something that you can teach currently, or is it something that you need to have some skills before you fill the role?
Cathy Theys:
So there's two different perspectives that I'm coming to this conversation with, and one of them is I worked for Lullabot, and I was involved in hiring some people recently. And I'm also involved with a bunch of Drupal user groups, where I interact on the regular with people who are trying to get Drupal jobs. And so I think the answer to that question is, it depends on what perspective do you have?
Cathy Theys:
Do you already work in a company that is a Drupal company, and what do you want to do? Or are you trying to get into the market, and trying to break in, and get a Drupal job? And if you're on the outside, you would like to say, "Look, I come with all of these related skills, I know about web, I know about sales, I know about all these things, I'm just missing some context about Drupal, please hire me, and I will learn about Drupal."
Cathy Theys:
Or you're inside the company, and you're like, "Whoa, our margins on profit are really small, we would love to hire people that come with all these skills, but how are we going to reconcile the training budget to teach them Drupal, and balance that with all of our other budgets that we have for sales, and professional development, and benefits that we give our employees. And so for me, who pays to teach people, is it the company, or is it the people coming in?
Matt Kleve:
Yeah, or a combination of both? There are certain cases where we may expect developers, or whatever role to have a certain amount of Drupal knowledge, but maybe not quite everything that we would hope for as long as they maybe show knowledge, and expertise in another place. Do you agree with that?
Greg Dunlap:
I do. And I think it also depends on what type of a business you're in too, because we are a consulting agency, and so our income is based on time build. And that makes us taking the time to train someone, or take on an intern or whatever, more difficult, because it inevitably makes our budgets for project higher, which makes us less competitive.
Greg Dunlap:
Now, for a different kind of business, the investment is different. So for instance, let's say, in the Drupal sphere, there are several venture capital backed companies, mostly hosting, that the whole point of taking venture capital, is to invest in your business, and to spend money now, to make money in the future. And it's not the whole point, but it's one thing that you do with venture capital money.
Greg Dunlap:
And so for them, investing in training, and mentoring junior developers now, is something that they can see payoff for later, and it's just a different model, than it is for an agency or a consulting company, and most of the hiring that happens in the Drupal sphere, isn't agencies or consulting companies. And so I think that's one of the things that makes it difficult in Drupal, and one of the reasons that we had end up with this problem of how do we manage junior developers?
Greg Dunlap:
Is that whole fact that the agency... And I'm not going to say it's impossible, plenty of agencies, I know that Palantir has an internship program, for instance, and I'm sure that others, especially at scale, make it work better. But at a certain size, especially agencies, the money model makes it more difficult for sure.
Albert Hughes:
Yeah, I think with Drupal, it's interesting, especially like you said that a company like Lullabot, or a company that we're selling Drupal services, it's harder to bring somebody in, and say they don't know anything about Drupal, let's teach them especially with Drupal being open source, and there being opportunities to learn, you almost need to have someone who wants to learn Drupal, or wants to be involved with Drupal, to come to an agency.
Albert Hughes:
I think there's other opportunities, where it's easier to bring somebody in, and let them learn Drupal on the job. My previous job, I had worked in other companies where, it was a company that had Drupal as their website, right? Whether that's an NBA teams use, Drupal websites, whether that's at other companies, but I think those are opportunities where a person can come in, not knowing anything about Drupal, get involved in a project, learn the website at that company, get some Drupal skills, and then move up the ranks to bigger companies.
Albert Hughes:
It feels either very small shops who may dibble and dabble in Drupal, somebody who ended up working at a university, somebody who worked at a company that happened to have a Drupal site that they learned, is almost what fuels a pipeline to then get people up to a bigger Drupal agency, versus the agencies being the cultivator of the pipeline.
Cristina Chumillas:
And it's good that you say that, because I have the feeling that right now, the Drupal projects in general are way bigger, and Drupal as a project is way bigger, and more complex that it was before. And we have a bigger amount of freelancers that they knew about Drupal, but they maybe also knew about corporate, and it doesn't happen anymore.
Cristina Chumillas:
Because if you specialize in Drupal, it's a different kind of projects where you end up. So we don't have these bigger base of freelancers, that can jump in, and have these basic knowledge [inaudible 00:14:27], the more they work on that. So I think that's a big change also over time.
Mike Herchel:
So when we're talking to at least for developers here, what makes a back end Drupal developer, a Drupal developer, do they need to know Symphony? Do they need to know the Drupal API's? Or, is someone that maybe comes in, and they know things Python, are they able to just switch over?
Matt Kleve:
I think that's tricky, so if we're talking about a back end developer, I think you have a lot more of a Drupal requirements, especially from a perspective of someone Lullabot hiring a Drupal back end developer, I think they need Drupal experience. So what does that mean?
Matt Kleve:
I think it means you understand what's going on within Drupal, I think you can write custom code for Drupal, you have a clear understanding of the bits at work, under the hood, I guess, would be the metaphor that always gets used. How stuff is happening within Drupal core, and the Contrib space, and what's going on there.
Matt Kleve:
I think it's a little easier this day to bring in somebody who is a PHP expert, but maybe not necessarily a Drupal expert, because of some of the standardization that's happened within the way that Drupal core is written, I think it's still a hard ask.
Matt Kleve:
Because there's still a lot of Drupalisms that are, "Oh, yeah, well, that's the way that works, because that's the way that worked 10 years ago." I think experience, Mike is the key. I'm going to guess that it's different from the perspective of hiring a front end developer, though.
Mike Herchel:
Yeah, so front end developer, and I'll shoot this over to Christina. If I'm hiring a front end developer to work on a Drupal theme, can I just hire someone that's familiar with WordPress, or do they need to maybe know a little bit of Drupal?
Cathy Theys:
Yeah, or what would a person needs to know?
Cristina Chumillas:
Yeah, that's a really good question, and actually, while I was on my last company, and even right now, when Matt was saying that, it was like, "Okay, I have no idea what is required for back end." But absolutely, for Drupal, for front end, you actually need a Drupal front end knowledge, you need to know the front end sphere, you need to know what [inaudible 00:17:03] process, you need to know, Twig, you need to know, obviously, PHP, you need to know how this connection between the template system works.
Cristina Chumillas:
And also, if you want to add in there a pattern library, it's another layer over there. And of course, you need to know JavaScript, and CSS and everything, but you can't hire, I mean, you could obviously hire a general front end developer, but if you're just throw someone, a front end developer into a Drupal project, they will say, "Okay, where do I started?" Okay, the things right here but, that's all,
Matt Kleve:
I've been on teams before where there have been front enders, who are working strictly within their pattern library, and don't know much about Drupal.
Cristina Chumillas:
That's true.
Matt Kleve:
As long as there's somebody there to bridge that gap, I think they can be very successful.
Cristina Chumillas:
Exactly.
Mike Herchel:
I would also like to add that Lullabot several years ago, we hired Hunter McDermott, who came in with just a whole bunch of modern JavaScript Ecosystem, and he was successful, but he was also successful, because he was on a team that had traditional Drupal front end developers, that when he had a question, he knew who to ask the question to, etc.
Albert Hughes:
[crosstalk 00:18:38] somebody has to know Drupal still.
Greg Dunlap:
I mean, I'm curious, because having lived through the Drupal eight cycle, as a core developer, I know that one of the big sales points of bringing in technologies like Symphony and Twig, was that it would make it easier to hire and bring people into Drupal.
Greg Dunlap:
So I put it to you, let's say that you had a developer come in, who is not just a PHP developer, let's make it easier, a Symphony developer. Or somebody who is a front ender, who had worked with Symphony and Twig before, but never with Drupal, would you hire that person, or not? All things being equal.
Matt Kleve:
What are the resumes do I have in my inbox, would be question number one. [crosstalk 00:19:27]
Cathy Theys:
No, no, not would you hire that person-
Greg Dunlap:
Would you consider this person, right?
Cathy Theys:
What would that person need, a person like that, What would they need to be successful in a Drupal job?
Greg Dunlap:
I won't even go that far. I will say if this resume landed in your pile, would you mark them as not qualified?
Cathy Theys:
Well, it depends on what the budget is, in terms of training the people.
Greg Dunlap:
No, let's say that all of the resumes that came in, there are a variety of skill sets, but they're all asking for the same money, let's just put everything on an even playing field, would you even consider someone who was a Symphony developer, who had never done any-
Mike Herchel:
I have a clarification question, are they on a large enough team, that they could ask Drupal specific knowledge to?
Greg Dunlap:
We can't guarantee that, because we don't necessarily know what team people are going to go on when we hire them.
Matt Kleve:
Sometimes, I mean, sometimes people get hired for a project, and it works. But I think what Mike is saying-
Mike Herchel:
They might see be sole developer, is what you're saying?
Greg Dunlap:
It's possible.
Mike Herchel:
Okay. So I would say right now, if they're the sole developer, and have never worked for Drupal before, they should not be hired for a Drupal project. If they can come in, and they can have a mentor, someone like Matt Kleve, God forbid, or Christina, or Cathy, or Greg, or Albert, hopefully not me, help them out, I think that they could be very successful.
Greg Dunlap:
I mean, so that is a dain from before, because I think we can all agree that back in the Drupal seven and before days, hiring somebody who was just a PHP developer, to do a Drupal was a much bigger ask back in those days. I would actually rather had somebody who had never written PHP, but who had been a coder, and bring them into a Drupal job, than somebody who had written PHP before.
Greg Dunlap:
Because I used to see that the PHP developers came in with a lot of preconceived notions about how PHP apps should work, and they hate Drupal because it didn't work that way. But it sounds to me like you're saying things have at least gotten better from that standpoint.
Cathy Theys:
And one other things about a Symphony developer, is that what I might be able to assume that they come to a Drupal job with, is things like object oriented programming, do you use an IDE, are you familiar with composer dependencies? Those kinds of things?
Greg Dunlap:
You probably know Twig.
Cathy Theys:
Are helpful, but it's not sufficient to do Drupal work, without being trained in the Drupal specific knowledge that they would need. And so if we knew they were going on a team with an experienced dribbler, or if we knew we could put them on a project internally, to learn Drupal first for a month, and then deploy them out to a non internal project. I think the key for me is, what overhead does the company needs to have in their budget available, to support people who need some training, in order to be effective in their job?
Mike Herchel:
I mean, I would argue if they can get mentored on the job, if you're a Symphony developer coming into a team that has a couple other back end developers, who are familiar with standard Drupal, site building and best practices, and things like that, at that point, I would say that they can be getting their billable hours immediately, and at that point, the customer, they're learning how to do views on the job, and then creating content types, and creating views on the job. And that's fine, because at that point, you have other developers reviewing their pull requests, and providing that mentorship.
Cathy Theys:
Yeah. So where does the money come for the mentorship?
Greg Dunlap:
Well, would you say that if they had two to four weeks, not on a project to dig into Drupal and figure things out, and go through Drupalize.Me about module development, and all of that sort of thing, that they would be able to hit the ground running on a project?
Matt Kleve:
That's hard. Yeah. I mean, I agree with Cathy, it's better than nothing, but I can tell you that if I were in those shoes, I'm not sure I would be successful with that, just because I know that I would not learn very well that way.
Mike Herchel:
Yeah. And to come back to your question, Cathy, where does that money come from for the mentorship? I mean, that comes from the client, those are part of billable hours. And in a normal project, developers are learning things. I might be learning about some new JavaScript method, or a new library. Like the project that Matt, Albert, and I are on, I had to do a bunch of research into some accessible carresol I'll type stuff, and that was our billable hours.
Albert Hughes:
I'm with that, as far as you had to find that balance, like you said, everybody's learning every day, so maybe within that billable, like you said, if he's doing site building work, if a person is creating basic content types, you're learning, and you're providing value to the client at the same time, so it's actually looking, I think, trying to find those win win moments, and it may have to be more intentional, if you're trying to bring somebody onto a Drupal project, who may not have the Drupal experience, it might be on the company to find that sweet balance, where it's a win win on both sides, to bring them up to speed, but also provide value at the same time.
Cathy Theys:
Such a good point, that even people who have Drupal experience when given a task on the job, they also need to do some learning, and I think on the balance, I think Mike is right, we expect those people to be able to build that learning time.
Cristina Chumillas:
Yeah, but that leaves us with the question about about juniors, how is that involved in a company that is actually going to bill hours anyway, but probably wants to start training some juniors, the money is going to come... I mean, obviously, it's going to come from the client, but it's going to be a part of the budget that the company has to account for, or take into account, on a separate way probably, I guess, if you'll want to start training juniors on purpose.
Matt Kleve:
Yeah, that's really good point, Christina. We're talking about hiring people on the Lullabot podcast, and coming up right after this, we're going to get into junior developers, and how we might be able to bring them in, or not, I mean, it could be an issue, right after this.
Mike Herchel:
Welcome back, we're talking to hiring in different roles on the Lullabot Podcast.
Matt Kleve:
Early on Mike, you we're going through the list of titles we have at Lullabot, and I heard something, and my ADD brain wanted to be distracted, and say something about it, but I waited until now, aren't you proud of me? You said something about at our company, and I was really happy to hear that.
Mike Herchel:
Yeah, Lullabot is what's called an [inaudible 00:27:23], which is a play a stock option or something like that.
Matt Kleve:
100% employee ownership is the key, yeah. So yeah, it is our company. So we're talking about passionate, ownership posoition, right? It's super fun. So Christina, I'm sorry, I didn't mean to cut you off before the break, but we were jumping into the thought of adding junior developers, and that's a question that has been at Lullabot for a long time, because it's people are hiring Lullabot because they are the Drupal experts, but how do we integrate juniors, and make them become seniors, and do that, and it's a challenge that's been going on for a long time.
Cristina Chumillas:
Yeah, I think it's a challenge for a lot of companies, especially they will notice that there are more remote companies, and I think on the junior perspective hiring people, it's also super important, because if you want more diversity on the hiring process, sometimes not setting the level can help others [inaudible 00:28:31], and you can actually go to other communities, or other places where various people that actually go to start, but they maybe haven't had enough time, create time to learn through, or all this kind thing. So I guess, also, always hiring juniors is a really important part for a lot of companies. And yeah, it's complicated, but Drupal is especially complicated thing.
Albert Hughes:
This might be really Drupal ish, but I was looking on the notes, and there was one role of Site Builder that we don't actually hire, I've never really seen a role posted for a site builder, but in the Drupal community, we know that there are functions, and there's a skill set of being a site builder. So just out of what came to mind is, maybe the junior developer role in the Drupal community, could be more like the site builder role.
Albert Hughes:
You can learn about Drupal, you can still provide something to the client, but you don't necessarily need to have a high level of Drupal development experience, but it could get you working with Drupal level developers, so maybe that's a thought of a solution is, maybe there is a need for a site builder role, to get the pipeline for people into Drupal to then become developers, that's just a thought that came to mind.
Matt Kleve:
I really like that Albert, and I agree with you, that's something that I would like to see try and happen. When this topic comes up, I end up saying... I'm on a lot of projects that are of a pretty good size, and there's a few developers all working at the same time. And there's an early point in the project, where you're building views, and content types, and stuff that any Drupal site builder can do, because it's the basic gardening stuff, we're setting up our website, and we're making it work.
Matt Kleve:
We're not doing anything in depth, and I think a junior person, could have a lot to gain from there, and I think we could then focus other things earlier, and get some of the harder stuff knocked out as well. I think it's a role that could work, but then it turns into a scheduling issue, it's like, okay, well, what do they do after the first six weeks, or three months of the project, do they hop on to the next one? And then how do we continue to train that person up, to grow them as something more, or not? I don't know.
Cristina Chumillas:
I truly, I think it's a role that could be actually work together with some experience on UX, because actually, the person that is doing all this side building is probably working on, and creating the forums, where the content authors are going to spend eight hours per day working on.
Cristina Chumillas:
And something that I recently discussed with a few people is that, actually, back enders are creating forums, and most of the time, bartenders don't have UX experience [crosstalk 00:32:02]. Yeah, and the forums are great, whatever they think they are the best. Let's say as an example, let's put meta tags on the sidebar, and try to open a meta tag details, and it just adds a huge scroll on your form. So this small things that are building the admin UI, someone with this experience, could also improve forums on the forum, on the administration.
Matt Kleve:
Yeah, back enders make forms, for example, [inaudible 00:32:44].
Mike Herchel:
Or [inaudible 00:32:50] Drupal six. Yeah. So maybe let's maybe talk about some different role.
Matt Kleve:
And to be fair, I love [inaudible 00:33:02], sorry.
Mike Herchel:
Yeah, well.
Matt Kleve:
It was my favorite.
Mike Herchel:
Boy, that's a podcast.
Matt Kleve:
Yeah.
Mike Herchel:
To jump into more cycling stuff, Christina, I'm curious in your traditional front end role, how much site building configuring reviews, content types, etc, do you normally do?
Cristina Chumillas:
That's a really good question. Before starting at Lullabot, for us doing the company I worked on, it was front end responsibility to create other forms, it was us that created all the site building. And the back of theirs were focused on other things, and when I joined Lullabot, I was, "Oh, but all the content types, and everything is already built. Cool. Perfect. I don't have to do that anymore." But I was used to do that. So I guess it depends a lot on the strategy the company's following. So, I don't know.
Mike Herchel:
I can tell you from my point of view, it's a very common test for me to go in, and reconfigure some views to get the markup, or maybe change it to use a specific view mode, or go into a content type, and change a field format, or something like that.
Cristina Chumillas:
Yeah. But for example, on the view modes, for example, on a front end perspective, if you are creating 20 view modes, and we could actually reuse the same view mode, and reuse the same template that points to the same pattern components, sometimes you could just reuse a lot of the stock. And obviously on our back end [inaudible 00:34:48], there are a lot of other advantages, of course, but they're always two sides on the same coin.
Cathy Theys:
I think Christine is on something here, where whoever does the site building task be then somebody who's learning Drupal, and being a site builder, or a front ender, or a back ender, there are some lessons learned that happen with experience. So if you're a front end, and you've received a site that has been built in a certain way, and you see that that impacts the future front end work, and makes that a lot more difficult and expensive, then as a front ender, you're going to incorporate that experience when you build future sites.
Cathy Theys:
And similarly, as a back ender, if you have received a site that has made some of your back end tasks very expensive, because of some choices that were made during the site building, you're going to take that into account when you're doing future site building. And so what about the poor person who hasn't had those lessons learned, how are they going to know? Well, when you build a thing like this, you're making a choice, and these are the impact of your choices.
Cathy Theys:
And I think the way for a person who is a site builder, or somebody who's coming in as a junior, and starting out with site building tasks, I think the key... Okay, now I'm going to express an opinion. In my head, I think they are more successful when their work is reviewed by somebody else. So they can say, "Oh, I see what you did here, when you built this form." The problem with that is that later, a month from now, this is the bad thing that's going to happen, and so because of that, we need to build this differently.
Cathy Theys:
The feedback loop for checking your work as a site builder is months long, years long, there's no automated test, that's going to tell you, you built something in a way that's going to cause you problems in the future, I don't know.
Cristina Chumillas:
So that's a really good point, and actually, how do you know that? Sometimes it's before building it. I remember one of the projects that I actually really learned a lot, and I actually like the process that we actually were with Greg, and there was a lot of planning on content types, on fields, reusing fields, and that's something that can be implemented also on bill modes, because later on, we actually started planning bill mode, that we're going to be reused, and which fields were seen on each content type, and that mapped into the pattern library.
Cristina Chumillas:
And if you invest some time first planning, together with a person that is going to build that, because that's going to be useful for that person, because that person is going to get that knowledge. I guess that planning is investment time, that it's going to solve future problems, and put all the knowledge together, all the team knowledge, at the same point. I am actually thinking on shield, spreadsheets, pointing, do more responsive images, sizes and these kind of things.
Mike Herchel:
Its a lot that goes into it. Maybe let's talk a little bit about maybe career progression, I've known several developers at Lullabot who have gotten into project manager roles, and then of course, we hire project managers directly to. When we have project managers, we call them technical project managers, but the question is what makes them technical, Albert, are you technical? I don't know.
Albert Hughes:
I would say, yeah, that's very interesting, technical project manager. I think that sounds almost like Drupal project manager, is really what is trying to say, a project manager who knows enough about Drupal to understand what's going on, maybe that is why it's called a technical project manager, I'm just wondering, I know, my background, I learned about Drupal, I would say really heavy in the site building, I think I've had some freelance or have had rows that had developer in it, but I don't know how back end developer I really give myself credit for.
Albert Hughes:
But I know about Drupal, I know content types, I know views, I know menus blocks, I know Drupal, and so I think that's what gives me the technical part of project manager, if I had to just sum it up what my thought thoughts were, is I think if I didn't know about Drupal, yeah, I would just be a project manager.
Mike Herchel:
Do you think having that background, and site building such as content types and views, do you think that, that informs your decisions, in how you approach your job?
Albert Hughes:
I think so, I would say it definitely gives you an insight of what's going on, and what needs to be built, how it needs to be structured. I think it helps, I think if I didn't know anything about Drupal, I'd be a little bit more difficult to jump into a Drupal project, and try to create tickets, or just try to discuss the project, and know what's going on. I had to understand, I see what this is, this needs to be a content type.
Albert Hughes:
I can look at a design and say, "These are going to be content types, this is going to be a view, this is going to be that." If I didn't know that, I think it may be a little bit more difficult.
Cathy Theys:
So what would you do? Lets say we had a project manager position open, and it was on a big team, it was for a particular SOW that was coming up, some project we were planning for, and hiring for intentionally. So it was on a big team, they were going to be surrounded by other Lullabots that know Drupal, what do you think a project manager... What would we have to do to support them? Could we hire a project manager, and what should we do to help them be successful managing a Drupal project?
Albert Hughes:
One of my things, I think, and it's me, if I was hiring for a Drupal project, and a project manager who when I looked at their resume, they didn't have necessarily Drupal experience. What would get me to hire them I think, is during that interview process, they've shown to me that they've went out there, and got some of the knowledge that's available around Drupal. To me, I know, that's a hard ask, but there is basic Drupal knowledge, there is a one, two to learn Drupal that I think if they hadn't done that if they knew that, "Hey, we're hiring for a Drupal project management."
Albert Hughes:
And you're applying for the job, and then through the process, you're like, "I still don't know anything about Drupal." I'm going to look at that like, there's a lot of opportunity for that person, to at least get up to speed, to learn about Drupal, prehand. And then at that particular point, I think there is opportunities to, during an onboarding process, or they've shown that they're willing to learn more about Drupal, I think there may be an opportunity to go to Drupalize.Me, learn some of the basic structure of a Drupal site, at least to get familiar with those concepts.
Albert Hughes:
I just think if you if a person hasn't done that to that point, I don't know if they will, and I may be off base, but I just feel like, if you're going for a Drupal project manager job, and throughout the process, you just was like, "I'm not going to learn anything about Drupal." You get hired, I don't know if you're going to-
Matt Kleve:
So Albert, it sounds like you feel there's a baseline of knowledge that's required.
Albert Hughes:
I think there's a baseline of knowledge required, or at least wanting to understand, and I think the baseline is, this is still open source, this is still a community, I think there's a very low barrier of entry to baseline knowledge, so that if you have not crossed that barrier, that may be the one thing, at least jumping into the water, is maybe what I'm thinking.
Matt Kleve:
If we could shift over then Greg, do you feel that there's the same when you're hiring in the strategy world?
Greg Dunlap:
I don't really, I mean, we're hiring right now for someone, and we had several people come in with Drupal experience, but missing other things that I wanted more, and I passed on all of them. None of my final candidates have any Drupal experience. There is one person who has some technical experience, for instance, some general CMS experience, and some, at least, the kind of experience that says, I understand how web pages are built, and what the implications of building webpages are, and that sort of thing, and I personally find that experience, equally valuable in my job as actual Drupal experience.
Greg Dunlap:
Because if a person understands how a CMS works, and how a CMS generates pages, that's most of what they need for my part of the job. I can teach them about the Drupal specifics of content types, and the Drupal specifics of fields, what views are, and all of that sort of thing, and it's pretty straightforward, and these people will never do any coding in their lives. And so for me, that background, it's just not as important.
Cathy Theys:
So it sounds like you find CMS experience though still still a key component?
Greg Dunlap:
Yeah, because I mean, one of the things that is really a key differentiator, I see in people who have worked with CMSs, and people who haven't, is that the people who haven't worked with CMSs, tend to have a much more page centric view of a website, whereas the people who have worked with CMSs have much more of a type centric view of a website.
Greg Dunlap:
And how they can build around types, rather than building individual pages, and that is really a key conceptual difference in how people build websites. And so once we get over that hump, then for me, the Drupal stuff for the kind of work that I'm doing is a pretty easy ask.
Cathy Theys:
I think it would be similar than for sales? Like a CMS experience would be really helpful, but maybe Drupal specific, is not quite as key.
Greg Dunlap:
I would say it's different for sales personally, because I think sales is about understanding a client's problems, and how we can address those problems. And so I don't think a salesperson... They may have to know something about Drupal, in as much as they know about the marketplace for Drupal, and what clients do, and don't about Drupal, and what we specifically can bring to the table to address those problems, but I think that is again more of a general understanding the issues of large scale technology, understanding the issues of large scale websites, as much as a Drupal thing.
Matt Kleve:
Its product knowledge, it's not [inaudible 00:47:03] but knowledge of the product that, you're not expecting a salesperson to build a view, but you maybe should have some basic understanding that views exists.
Greg Dunlap:
I think it's much more important for a salesperson at Lullabot, especially to understand what we uniquely bring to the marketplace, and what we uniquely bring to solve customer problems, as a company much more than any of the individual technologies that we work in.
Mike Herchel:
Before we jump away from content strategy, though, Greg, you have a couple different roles in your department, there's content strategists, and then there's a new role that you're hiring for a content designer. Can you talk about what the differences are?
Greg Dunlap:
Yeah, I mean, to some extent, that reflects a change in the industry, as far as what people are calling themselves, as much as it represents a change in actual job function. I think people will say that content designer, and content strategist are different roles in general, content designer is an evolution of a role that was traditionally called UX writer, it's somebody who brings a much more writerly, and editorial experience to the table, then a content strategist, who tends to be bigger picture.
Greg Dunlap:
And that's a skill that we have found is lacking in our group, so it's one of the reasons that I decided to call it content designer, and it also reflects, again, trends in the industry, as far as what titles are, and things like that. But functionally, I don't think that internally at Lullabot, there will be a very significant difference in those two roles, and we've actually had discussions about whether or not the new hire, will actually be called content designer, or not, anyways. And we've had those discussions with the potential hires too, so it's not like we're dropping bombs on them or anything.
Matt Kleve:
We're going to hire you as a content designer, but you're going to be a back end developer, good luck.
Greg Dunlap:
Yeah, surprise. I will say that one other role, though, that we have in our group is the UX strategist role, which is fairly different, and it's a bridge between content strategy and design, in that it's very much focused on end user experience, and so there's a lot of issues around designing interfaces, around user testing. Like Marissa, our UX strategist is very, very well versed in UX testing, and how to get answers out of users through testing, and data collection, and stuff like that.
Greg Dunlap:
So that is a role that we have that is different than the content strategist, but on the other hand, I'd say that that role requires probably even less intimate Drupal knowledge than the other one does, except in as much as she, and our designers want to design things that can actually be built in Drupal, which is important thing to keep in mind. But once you get over that hurdle, I would say that doing actual Drupal work or understanding Drupal under the hood, and that thing is probably not as important.
Cristina Chumillas:
Yeah, just pointing out that probably the [inaudible 00:50:19] that Greg said about not building website, pages, I mean, it's a key concept that I would say any designer, or strategist should have in mind, because that's a really important thing in Drupal.
Mike Herchel:
I have a question, talking more about career progression here is what is the differentiator to make someone senior? For example, my title is senior front end developer, what makes me a senior front end developer? What makes Matt a back end developer? We do the same job, but where's that difference?
Matt Kleve:
You're saying the difference between you're a front end developer, and you became a senior developer, and there was a line down somewhere?
Mike Herchel:
Yeah.
Matt Kleve:
Titles, basically. I would say experience, I mean, I don't know how to draw that line, other than the person probably is able to do more types of things without stronger guidance, I don't know, I'm making things up now.
Mike Herchel:
I was thinking of mentorship too.
Cathy Theys:
So the answer to this question is on the VPN.
Matt Kleve:
So I have to go look at the Lullabot handbook to figure that out, or?
Cathy Theys:
Yeah, so I don't want to switch to the VPN, while I'm on a podcast. But one of the things that... So Lullabot has 50, 60 people employed, right? Total. That's everybody, all of our project managers, all of our admin team, everybody. And so that's not really a big number, it's a big number, but not. But we're at the point where we need to be able to explain to people, what is the difference between a senior, or not senior, or an architect, and not architect, or a lead, and not lead?
Cathy Theys:
And we are just starting to put those differences into documentation, and so I think we have, I don't know, like four, a few roles with a document that says, "This is what this role is?" And I think that question is still in front of Lullabot, we are still trying to clarify that, but we're firmly actively involved in trying to figure out what that is, like this year, next year, that's a real active place that we're we're documenting.
Cristina Chumillas:
Yeah, it's something that I think it's actually changing a little bit over the time, is that we came from a place where we have front end and back end developers, we didn't have that many roles in between. There's also now the full star, there is also the novel role between design and front end, there are a lot of roles that are emerging, not on Drupal, just Drupal, but in general on the web industry, as Greg said, things are evolving, and titles are evolving also together with that lie.
Cristina Chumillas:
And new roles are being created, the bigger the industry is becoming, so more specific roles. So not always a path to the top becoming a senior maybe, it's becoming very more specialized on something in between.
Cathy Theys:
Yeah, for example, DevOps, that's a thing that is... In terms of the web evolving, that is a role that we might hire for.
Matt Kleve:
So now on a different path, a couple of years ago, we hired a bookkeeper, did they need Drupal experience?
Mike Herchel:
Only if we ended up doing what we always do, which is building our bookkeeping system in Drupal.
Cathy Theys:
I'm going to make them use Drupal.
Matt Kleve:
Thank God we didn't, so the answer is no.
Greg Dunlap:
No, yeah.
Cathy Theys:
But Matt has a good point, because when we're thinking about the roles that a technology company that does Drupal is hiring for, quite often, Drupal is useful to do the thing, but there are positions where you don't need to do that. And I think there are people who want to get into technology, who should know that, they need to know that you can have a job in technology, that there are some places where you don't need to have specialized knowledge, but you can still get in on it. Like, yeah, come on.
Albert Hughes:
I think that's a good point is where, especially I think, and I've seen this in a lot of diverse.... In a lot of diversity initiatives in technology, are always here coding, are coding, boot camps, [inaudible 00:55:55] code, Girls Who Code, and what I think really should open up is more of getting people into technology, modern technology jobs, and the modern technology industries, and I think there's a lot of focus on coding, and not a lot of focus on the different jobs, that you can get within technology companies, that is the modern day business.
Albert Hughes:
So whether that's admin, whether that's bookkeeping, whether that's project management, content, UI designer, all the different jobs, I don't think there's a lot of emphasis in these other communities, and those initiatives that just says, "Hey, just come join us period, you don't have to code." Because everybody, it really takes a specific discipline, to be a back end developer, who is in code doing that, it takes a really specific type of person to be a front end developer, and want to see things, and build things using code.
Albert Hughes:
Everybody does not have those skills, everybody doesn't fit in those groups, but could have a place in technology, or at a company, and then maybe get exposed to some more of those things, and go over time. And I think some of those perspectives can help the different technology communities, but I think a lot of times, the initiatives are more focused on code, code, and versus giving these different ways that you can get into these modern technology companies without coding.
Albert Hughes:
And I think that's one place I see where if you go back to the pipeline, and you start talking about that, I think that's one thing that hinders the pipeline, as some people call it, is that if a lot of people get just turned off of coding, and they feel like, "I don't code, so I can't be in technology."
Cristina Chumillas:
Yeah, that's a really good point, basically because a lot of times when you reach that person, that is maybe thinking about switching careers, or is just starting to think what they're going to study, or I don't know, whatever the spot that they find themselves, sometimes it's like, "Oh, if I want to jump into the tech industry, should I spend whatever years on university? Spend a lot of money on that." And maybe it's not that much if you want to get into the tech industry, either because you don't need to really become an engineer to the front end, for example, or to design, for example, or for some specific things.
Cristina Chumillas:
I mean, there are different levels, even for Project Manager, there are a lot of things, either boot camps, or I don't know, I guess, it depends a lot on the field. But yeah, sometimes starting at some point, it's related with hiring junior position also. And how do we get to that people these information about you have these options.
Greg Dunlap:
And also, there's one thing I'll say positively about, Lollabut, it's that it's a great place for people to find their place once they do get in, we've encouraged a lot of people who have been hired for one role, but found interest in another role, to help them find their way into their new role. We've had coders who have gone into the sales team, we've had coders who were coming into content strategy, we've had coders who've become Pms. And I don't think we've ever had anybody come from one of those roles into coding, but it doesn't mean that that couldn't happen.
Greg Dunlap:
And I could totally see a place where that could happen internally at Lullabot, and where over time, we could make that mentorship happen, especially in somebody coming in a role that doesn't have the overhead of being billable, because that changes our calculus in a lot of ways. So, I don't know, I think that's a really interesting thing to look at, and think about.
Mike Herchel:
Let's talk a little bit about about the pipeline. Albert, you and I are working with Discovered Drupal, do you want to talk a little bit about what that is?
Albert Hughes:
Discovered Drupal is a 12 month scholarship, and training program for underrepresented individuals 18 or over, you get access to scholarship support, skills training, Drupal career focus, tracks, whether they're site building, front end development, back end development.
Albert Hughes:
You get a chance to work with a mentor, who can share their experience, and support you, and then you also get to attend DrupalCon. So that's the definition. And in short, I think it's just a program and initiative, where we can help connect some dots, and address that pipeline issue.
Mike Herchel:
So Albert, you mentioned a pipeline, and we've mentioned that several times, can you talk a little bit more about what the pipeline is, and what problems that we do have with Drupal pipeline?
Albert Hughes:
Yeah, I typically hear pipeline when it comes to hiring it, I see pipeline as a pool of people of qualified people who are interested in a job, maybe there isn't a opportunity for the job, or we're not hiring today, but if we start hiring, do we have a pool of candidates that we can go to, or that meet a certain needs. So a group of qualified people, who could get hired, or qualified to get hired, but we may not necessarily-
Albert Hughes:
It's like having people in the bullpen, right? It's like if you were playing baseball, it's having a bullpen, we can go there, and get people if it's time to hire, that's what I understand a pipeline, and I've heard it a lot in different meetings and conversations around diversity, and there being a problem with the pipeline, basically saying there's not enough underrepresented people, who are qualified, so that we can hire underrepresented people when it's time to hire. So that's what I got from pipeline.
Mike Herchel:
Yeah. And part of discovered Drupal is it provides a little bit of that pipeline to underrepresented people, so they can get in, they can train up on Drupal, and hopefully be placed in a junior Drupal role, and at that point, just move up that career letter.
Cathy Theys:
Yeah. We'll have a link to the Discovered Drupal initiative in the show notes, but I think one of the things that's cool to highlight is that when we're thinking about, bringing in people who are juniors, or bringing in people who have expertise in another area, but are missing in Drupal, I think the Discovered Drupal initiative is one of the solutions to help open up that to more people.
Cathy Theys:
And there's a bunch of people involved, we know about discovered Drupal, because Laullabot is a platinum sponsor of this initiative that the Drupal Association started, but also Drupal Easy, Evolving Web, Drupalize.Me, Mediacurrent, these are some of the big movers and shakers, in terms of mentoring and training. And I think this is a cool thing, because it's systematizing, what do you need to know about Drupal specifically, where it's going to elevate your other skills that you bring to the table.
Cathy Theys:
You have all this experience, or you have all this initiative to learn, you've all this curiosity, we're just going to give you this little bit that's this Drupal part, and how are people supposed to know? Are they supposed to learn about Drupal if they don't know Drupal? We hand wave, and we're like, "Go on Drupalize.Me and learn something."
Cathy Theys:
This is helping to put in place a system of training, to help people learn the things that you might need to know. And I'm really excited about this, and there's a lot of really good trainers and mentors that are involved in this program.
Matt Kleve:
Cathy, is there anything you would to add as we point toward wrapping this up?
Cathy Theys:
I think one of the things is that I want people to know is that if you're on the outside, and you're looking at these sweet, sweet Drupal jobs, and wishing that you could get them, that there are people 'on the inside', who want you to get them. We're just, I don't know, trying to figure out how to do that, and it's not easy, and we're still thinking about it, and we're trying to brainstorm, and we really want to make it happen.
Matt Kleve:
Albert, do you have any final thoughts?
Albert Hughes:
Final thoughts would be, if you are looking for a Drupal job, or you want to get into it, I think it's just about jumping in, don't be scared to go online, get some resources, knowledge up, and apply, and just do your part too, and then from a job, and speaking to companies out there, I say maybe look into their site builder role, which is a way to increase your pipeline, and to bring people in a soft way, and invest in people.
Matt Kleve:
An unsuccessful application project, is just successive practice for the next one, right?
Albert Hughes:
Yes, sir.
Matt Kleve:
Greg, do you have any final thoughts?
Greg Dunlap:
I don't know, I think that we find ourselves in a tough space, because we have a product that requires, for better or worse, a lot of specialized knowledge, as we've determined in order to get hired, and we as a company have typically only hired people that have that specialized knowledge, and a lot of our business model is designed around that, and I think that puts us in a spot where a lot of us are very interested in figuring out how to hire juniors, or how to mentor, or how to put together an internship program, or whatever that looks, and figuring out how to make the business work around it.
Greg Dunlap:
And we have not always been the best at that, because especially when you hire new people, the worst thing you can do is hire a new person who is, a lot more junior than the others, and throw them in, and say, "Sink or swim." Because that's not that's what we typically do with the people that we hire right now, and that's not going to work for a new person.
Greg Dunlap:
So I think that one of the reasons this came out, is because there has been a lot of talk internally with us about how can we change things... How can we change the way that we work, in order to make that possible? And it's something that we are continuing to work on, and I think that a lot of companies are continuing to work on. And there's a lot of challenges there, but it doesn't mean we shouldn't still continue to think about, and work on and try and find solutions to it.
Greg Dunlap:
And I think there are a lot of different ways towards that, and we've talked about a lot of them today. And it's just something we need to continue focusing on.
Matt Kleve:
I think somebody at Lullabot would probably argue with sink or swim is the way we do it now, but, I understand-
Greg Dunlap:
It literally says in our employee handbook.
Matt Kleve:
I thought they changed that recently.
Greg Dunlap:
No, it's still there, I literally read it-
Cathy Theys:
I'm on the committee, and we are reflecting on that sink or swim mentality, but it is totally accurate that that was the mentality in the past, and we are reflecting on whether or not that should be our mentality going forward, to a great deal because we find it not supportive of hiring people from other industries, and junior developers, and we want to we want to make a change to that.
Matt Kleve:
Christina, do you have any final thoughts?
Cristina Chumillas:
Yeah, probably what Cathy just said it's super important, hiring junior roles, and knowing how to do that, and how to involve them, it's really something important for our company. And I think it's also super healthy for a company to get other roles, that are not just senior, and on a different perspective, and also for people that really want to get hired, and want to start on this technology, in let's say Drupal, I would say, just go and try it for a junior role, because sometimes there is going to be a lot of companies that are willing to expend that time, and that resources and efforts on getting people to know Drupal, and they are fine doing that.
Matt Kleve:
Very good. Hey Mike, so that's that's it, are you raising your hand, what aer ypou saying?
Mike Herchel:
Yeah, I have a final thought too.
Matt Kleve:
Okay, Mike.
Mike Herchel:
Thank you, Matt. One of the things I really like about discovered Drupal is that the trainees are going to DrupalCon at the end, I want to throw out there that the importance of in person events is great, they allow junior developers to learn and experience new things, and meet people, meet potentially mentors, and things like that, and get involved in the community.
Mike Herchel:
And I think it's been a shame that a lot of this stuff has been... With COVID we haven't been able to do these things like we have in the past, but as soon as that opens up, hopefully with New England DrupalCamp, [inaudible 01:10:24] Drupalcamp, and DrupalCon, hopefully things will get back to normal, and we can get these junior developers into the community participating, and learning new things.
Matt Kleve:
In person events, here's to hoping Mike?
Mike Herchel:
Yeah. Any final thoughts from you, Matt Kleve?
Matt Kleve:
No, thanks for joining us, it was a good podcast, lets do this again.
Mike Herchel:
Bye everybody.

Published in

If you enjoyed this Episode, you may also enjoy...

About host Matt Kleve

Portrait of Matt Kleve
Matt Kleve has been a Drupal developer since 2007. His previous work in the media sparks a desire to create lean, easy to use workflow processes.

About host Mike Herchel

Thumbnail
A senior front-end developer, Mike is also a lead of the Drupal 9 core "Olivero" theme initiative, organizer for Florida DrupalCamp, maintainer for the Drupal Quicklink module, and an expert hammocker