In this series, we illuminate open roles by going beyond the bullet points and chatting with Delphies about new opportunities on their teams. This month, we sat down with Director of Web Development, Charlie Darney, to talk about his Delphic experience and growing the Drupal development team.
You’re one of the most tenured Delphies in our ranks, having started in a junior role and worked up to director of your department. What was Delphic like when you started and how have you seen the development team grow over the years?
A great thing about Delphic is, if you’re accountable and strive to do a great job, you’re rewarded with opportunities to rise in the ranks and grow deeper into your practice. When I started as a junior web developer 6 years ago, I began working on legacy CMS code and as my abilities and interest grew, I was able to join and lead bigger back-end Sitecore projects and have been enjoying it ever since.
As for growth within the development team, for my first four years here, the back-end team was made up of four developers before shooting to 13 developers over the course of a year in 2015. In addition to changing the team dynamic, this growth has also changed the way we develop projects. Whereas being a smaller group allowed each developer more complete project ownership and the freedom to code in their personal style, growing the team has required us to standardize our code, so that developers can transition in and out of projects as needed and know what’s going on in a project without much ramp up time.
How big is the development team currently?
15 including the contractors we work with regularly.
Can you talk us through the project development process? What are the typical steps and moving parts?
We want to keep our technologists involved throughout the project definition and design process to make sure we’re keeping them within scope of both the project’s requirements and the capabilities of the technology we use. Being involved in the wireframing and design process allows us to have a better starting point when we begin building out the user stories and tasks. It also allows us to set up the necessary development environments earlier. Once the project reaches the development phase, we split everything out into sprint plans – we use a bit more of an Agile process during the development phase and a Waterfall approach during the UX, design, and QA, phases.
Naturally, we work closely with the front-end development team so, at the beginning of the development phase, we’ll sit down together and ensure that we’re aligned on the strategy. Then we just dig in and start coding. The way our practices work, it can be conflicting if we try to do certain things are the same time, so we stagger things whenever possible.
We’re looking to grow the Drupal team within the existing development practice. How do you see the Drupal team fitting in and growing within the broader team?
Sitecore development is our bread and butter, so the Drupal team has been kind of like a little brother in that more attention was focused Sitecore projects company-wide. The bulk of the Drupal and PHP work used to be very small projects but, in the last few months we’ve had much bigger projects come in, so the tide may be changing.
Ideally, the Drupal team will consist of two full-time developers with additional contractors brought on to scale. This structure has the potential to bring in a lot of new ideas, perspectives, and development styles into the Delphic development workflow, thus growing the solutions toolkit of both our developers and the contractors with whom we’ll be partnered.
I see the development team as a big Venn diagram; on one side there’s the Sitecore development knowledge, on the other Drupal development knowledge, and in the middle, a bit of overlap where both teams can come together to collaborate and problem solve.
Walk us through a day in the life of the Drupal team.
As previous department heads have mentioned, most often we walk in not really know where the day may lead. When we have dedicated projects – fixed timeline, fixed hours, fixed number of pieces to build – that’s typically more straightforward. You know that you’re coming in and working on user stories for that particular project.
Retainer work, however, is more on the fly as it could involve answering client questions, providing project estimates, and troubleshooting websites all in the same day. This gives our days endless variety, not only in the types of work, but also in the clients and the technology. Some days we’ll handle a WordPress site, two Drupal sites, and a Magento site before lunch. It helps keep things fresh.
As the Director of Web Development, the Drupal team would roll up under your purview. Describe your management style.
I like to let the developers I lead figure things out on their own rather than immediately answer questions. I’ve been known to answer a question with a question. I want to make sure people learn to figure out their problems – teach them to fish, so to speak. Other than that, I like to give them space to manage their own days and be a little more hidden behind the curtain, checking in as needed. If they’re not where we need to be, that’s when I step in, rather than constantly micromanaging. There are too many other things going on and nobody wants that kind of pressure. I know because I’ve been there.
Outside of project-specific check-ins, one thing I do is to check in with each team member in the morning and again in the afternoon and at the end of the day. Just a quick, “Hey, how was your day? How did everything go?” Even if I know it was a bad day, I still ask to give them the opportunity to speak up and hopefully not carry any negative feelings from the day home with them.
Why would a Drupal developer choose Delphic over a Drupal-specific development shop?
We keep hitting on this point but our culture is definitely one of the biggest difference makers for us. On the Drupal team, even though you’re coding different types of projects than the rest of the development team, you’re still fully involved in the team dynamic and wider company culture.
As for the work itself, at Delphic we get to work with a vast variety of clients across industry verticals and each projects comes with its own unique challenges and solutions. In choosing Delphic, you’ll join a Drupal team that not only codes projects but is involved in making strategic technical recommendations for our clients to ensure that we’re going beyond basic project delivery and thinking long term and holistically about a client’s digital presence and their website goals.
While the bulk of our business is Sitecore, we take care not to treat Drupal projects like secondary priorities. In fact, we’ve had quite a few clients come in asking for Drupal and specifically want to work with Delphic because they’ve seen our work. So, yeah, I think there’s plenty of reasons to want to be a Drupal developer at Delphic.
What questions should someone ask themself before applying to join the Drupal team?
Not even specifically for the Drupal team but for Delphic in general, what kind of environment do you want to work in? If you’re looking for a slower paced, more methodical setting, you may be disappointed that that’s not our everyday. By nature of our industry we have to be nimble and think on our feet. Is that the kind of person you are? Are you able to forsake perfection to iterate quickly? That’s Delphic overall but especially the development side. We’re fast-paced and constantly iterating.
Another important question is, “how much support do I need as a developer?” You’re potentially joining a team where everyone’s fully loaded with work so we don’t do a ton of pair programming, mostly for the sake of time. Code reviews and support are always available but having two developers sit down to complete one task together usually isn’t feasible. In this sense, autonomous personalities may find this team structure more favorable.
Describe the development team in three words or less.
Über nerds 🙂