5 Steps to Build a Great Drupal Team: Step 2: Define your requirements
- Step 1: Understand typical teams, roles and job titles
- Step 2: Define your requirements
- Step 3: Widen your net with your job description
- Step 4: Where and how to post jobs
- Step 5: Evaluating applicants
We're inviting feedback, so if you have built a great Drupal team or you have a process to share, we'd love to hear from you in the comments.
Step 2: Define your requirements
Researching your requirements is a key step in discovering your next team member. People can’t be experts in everything. Be realistic about the actual expertise and levels you expect. Requiring both “systems administration” and “CSS/Sass” expertise in one role is not going to attract qualified candidates. If you need a generalist to fill out your small team, consider what key areas you need them to be knowledgeable in. Also consider how you can provide mentoring and training opportunities to help develop junior talent.
Building a Drupal dream team
- A Drupal configuration expert: “This person doesn't need massive amounts of coding, but they do need to be comfortable using all of the tools available with Drupal.”
- A senior developer, who acts more like a solutions architect: “They are involved in planning. They research possible solutions, and play around. When they provide demos to the client, this helps discover those little 'hidden requirements' the client didn't mention.”
- Drupal theming: “This can justifiably be split into 3 tiers. Someone who is comfortable with manipulation of popular base or starter themes; someone who can manage custom theming; and someone who is a pure front end expert.”
Because Zoocha often gets clients who have failed with other agencies, Will started to realize patterns were emerging. "It dawned on me why some Drupal projects fail. The teams don't have sufficient depth to be able to take on complex projects," Will said. He explained that small teams with one person doing all the work of site configuration, module writing, theme development and Solr configuration aren't appropriate for complex projects. “Once you get to the budget levels of £30-60,000 and you have reasonable levels of customization and bespoke PHP code, you need a more diverse team to manage the challenges.”
In four years, Zoocha has grown to a team of about 20 people, and Will explains they don't outsource because they’re growing together to become a complete team of Drupal solutions experts. Will said a particularly challenging project helped his company mature. "It got nearly to the point where everyone would have been pointing the finger to everyone else. Acquia put a lot of support into it." Will credits the Acquia Professional Services team-- including Chris Comparato, vice president of customer solutions and Hernâni Borges de Freitas, technical team lead-- for helping to keep the project on track. "We've learned a lot about how to manage a client." This has lead Zoocha to a more agile way of doing things.
Training is an important component of professional development at Zoocha. To develop their own skills in working with Agile methods, they brought in a professional scrum trainer who trained Zoocha and a client together. In this way, they learned not only Agile methodology, but also how to work with your client using Agile methods.
I asked how Zoocha planned on managing the conversion over to Drupal 8. Will said, "Our current site was built on Wordpress in 2009", typical of the cobbler's shoes problem of course, "We're relaunching the site in Drupal 8; this is a complete refresh." Overall the moved to Agile has helped them become more efficient and free up capacity so their team can afford to play and learn together.
Getting access to information like this is difficult for agencies that are just starting out in Drupal. With our partner program we do try to help guide teams to best practices and processes that will make your projects more successful.
Are you scaring people away?
As we saw in the case of Zoocha, you’re not going to find a unicorn that fits all your needs, and yet employer still post the most unlikely job descriptions. Adding more skills, qualifications and specifications doesn't widen your potential pool of applicants; it has the opposite effect.
I think such puffed-up job descriptions scare off qualified candidates who don't have the outsized ego to consider themselves experts.— J. Renée Beach (@jessebeach) October 29, 2013
As well this can affect the diversity of your pool of applicants. A respondent to Jesse's tweet, Buffy Miller @buffym, pointed out that at Hewlett-Packard, they found that “women only apply for jobs for which they feel they are a 100% match; men do so even when they meet no more than 60% of the requirements.” ("The feminist mystique; What must change for women to make it to the top", Economist, March 2013).
It’s important to have a realistic requirement of years of experience; and specify what elements are the truly “expert” skills or experience you require.
Correlate years of experience to job titles
Reviewing recent job descriptions posted on the official Drupal job listing, the level of “rank” seems to correlate to the number of years of required work experience.
- Senior Drupal engineer or team lead equals about 5-7 years minimum web programming experience; 2-5 years of Drupal.
- Drupal developer equals about 3 years PHP development; 2-3 Drupal.
- Junior level equals about 1-2 years experience.
There are outliers among the listings, but you have to be realistic. If you expect to get someone into a mid-level paid job and you’re asking for 7 years of experience, you have to accept your responses will be low.
XKCD’s “Tech support cheat sheet”
What expertise do you need?
As you prepare your requirements, be careful in using phrases such as “expert knowledge of…” Often, employers specify they want “expert familiarity” and “expert knowledge”, which both are vague concepts in any knowledge domain. It’s worse with web technology where knowledge and familiarity can be wiped out with a new version of software or a new specification.
XKCD’s diagram above has some truth to it! Expertise is more likely the ability to learn and adapt, which is demonstrable by flexibility to learn something new, ask questions, take risks, and play.
Instead, define your requirements by using words that specify what skills you’re expecting to see demonstrated on the job. Bloom’s taxonomy defines measurable learning objectives, and it can be a useful tool for defining your skills requirements. Try these verbs to clarify the kinds of tasks you expect your prospective employee to be able to undertake in their role:
As you define your requirements, ensure you’re clear on what is really a “must have.” Our partner, PreviousNext has some good headings in their job descriptions which emphasize what’s required versus what is merely desirable. In a recent job posting, they don’t use the word “expert” once actually. Here are the example headings:
- Responsibilities include:
- This identifies the tasks that the role carries out on a day to day basis. While these are requirements, it leaves the possibility that individuals could be trained for certain tasks.
- Candidates will need to demonstrate:
- This outlines the previous experience which PreviousNext is expecting they will find from the qualified candidates.
- This outlines capabilities or experience which would set out a candidate from other applicants.
With this approach, PreviousNext widen their net and increase chances of finding someone who matches their most important requirements. It also helps applicants understand how they can set themselves apart from the rest.
Do you have good examples of job descriptions you’d like to share? Or do you have a formula for a Drupal Dream Team? We’d love to hear more.
If you’d like to know more and talk with one of our experts here at Acquia, please sign up to our online session with guest speaker, Summer Swigart, Practice Manager.
Sign up to our training newsletter
Sign up to our training newsletter to be notified about more tutorials for you. Please also check out the Drupal Training events calendar