Before starting Tiny Ships, I worked on projects ranging from a Point-of-Sale system for an antique shop in Buckhead to international restaurant and technology marketing campaigns. Back when I was just getting started, it was easy for me and other inexperienced developers to get frustrated with clients and project managers. I bemoaned vague feedback, tight timelines, and backseat drivers. I shared stories from Clients From Hell and thought I was cool for complaining out how the businesses I worked for didn’t hand select the perfect client for me every time. Pretty ridiculous.
Later on I moved into director positions – running development teams, and getting more involved with client strategy and training. And I started to realize that behind every person that came to my desk or emailed me for something I didn’t quite understand or agree with, there was someone behind them. And someone behind that person, and so on. The project manager that would literally sit on my desk (you know who you are) waiting for me to wrap something, was trying to help a marketing strategist with a tight deadline. And that marketing strategist was trying to satisfy a CMO that was tasked with meeting ever-expanding growth projections. Everyone was just trying to do good work.
I’ve written before, and will again, about how developers can be better advocates for their work and for proper process. But for this article I’d like to focus on what the teams and clients around them can do to get the best out of developers, and build a successful support relationship.
Talk to your developers early and often
Development work tends to be very downstream, meaning that a lot of discussions and time have passed before you get to the person who writes code. This is because developers are seen as the execution step of a project. So they generally aren’t included during discovery, strategy, and sometimes even architecture. They are brought a fully formed solution, and all they have to do is execute.
A seasoned developer will see the holes in a plan right away. And because so much time as passed and deadlines loom, there is hardly opportunity to push back. But, a seasoned developer also knows where the blame will lay if they don’t speak up. And so, you get tension, and deadline extensions. Or you push forward, and the developer’s portents come true (usually).
My recommendation is to involve developers earlier on in the process, and give them opportunities to weigh in. For example, if the design team just finished wireframes for a new project, include a developer in the internal review process before it goes to the client. They’ll have feedback on the editor experience, design impacts on timeline, performance, heck even ADA compliance. They might see ways to automate manual site tasks that they otherwise wouldn’t have had time to implement. They might even have one or two good ideas about UX! Some good times to involve developers:
- The sales process, to suss out technology hurdles
- Discovery, via a site audit
- Integration planning (mapping an MAP to a CRM, mapping a CMS to Analytics, etc)
- Design, especially IA and Wireframing, to give overall feedback and inform timelines
- Post-launch, to guide optimization efforts
Developers are problem solvers. It’s the thing they are best at. So the more you bring them problems early on instead of pre-determined solutions, the more value you’ll get from their experience and expertise.
Don’t interrupt developers constantly, but do interrupt them
We all need time for deep work, and developers are no exception. Studies have shown that switching gears too often can decrease efficiency by up to 40%. And when you’re paying someone’s salary or hourly rate, that’s quite a lot of money wasted. Adding to that, development doesn’t exactly lend itself to quickly jumping in and out of. Here’s an example: You ask a frontend developer to change the footer background color from a muted grey to a dark grey for better contrast behind white text. You’ve got the hex code and everything, it’s a 5 second change, and you tell them to do it right away. Here are the steps that I would personally go through to make that change, assuming the project wasn’t already open.
- Open my git UI (I use the terminal because I’m old) and navigate to the project folder. Pull the latest code from the master branch.
- Create a new branch, named after the change or ticket number, such as issue/1234.
- Start my local copy of the site.
- Start the frontend build process (probably webpack).
- Open the site files (I use PHPStorm) and find the footer styles file.
- Do a quick search to see if the hex provided is already a named color variable in the project. If not, I might consider making it one!
- Update the footer color.
- Check my local site.
- Commit the updated code and push my changes.
- Create a pull request to merge my new issue branch into master.
- Go through the code review process! This could be several steps depending on the project, but let’s assume for this scenario that it’s just me today and I’ll merge it myself.
- Deploy the master branch to the test environment.
- Assign the ticket back to the requester and let them know it’s ready for test.
- Await confirmation.
- Push live during the next scheduled deployment.
I’m a seasoned developer, so despite being many steps this won’t take long at all. But I’ve still completely shifted gears for a quick change, losing not only the time it takes to get into this project, but also the time it takes to get back into what I was working on. And the solution to this particular scenario is simple and obvious: just don’t ask for it right away. Open the ticket, give it a priority and due date, and the next time a developer works on the project it’ll get done, along with other open tickets. By batching, the developer is allowed to work deeply, even though they might be working on several problems during one stretch.
I’ve worked at both ends of the spectrum. In the agency world, developers have very little time for deep work, just like everyone else. Agencies are meeting-obsessed, not to mention constantly chatting and emailing, so dedicated time is very hard to come by. On the other end, I’ve been client/SaaS-side, where developers huddle in a dark room with no interruptions except a 15 minute standup meeting.
If you have to choose one, choose the later. At least then developers can get work done. But ideally developers are given several hours of uninterrupted work every day, and are brought into important conversations. Some developers can only bring value when they code, and that’s ok. But the vast majority have a lot more to offer. After a while, some will ask to be included rather than waiting for the invitation.
Encourage developers to learn about your business
Developers love learning. It’s a prerequisite for building talent as a developer, as the world of technology is constantly changing. So put that drive to good use. Are you running a marketing agency? Do you your developers know the first thing about marketing? No? Cause I guarantee your project managers have learned quite a lot about code, and your account managers have learned a lot about content. Take the time to involve your team in the facets of your business that they don’t touch on daily basis. Developers are often so siloed that they lack the growth opportunities that other team members happen upon organically.
For agencies, I highly recommend using the Hubspot Academy to give developers an introduction to marketing, content, and lead engagement. The lessons are easy to follow for the initiated, but surprisingly deep. I’m still reeling from the lesson on Topic Clusters and Pillar Pages.
And the point of this recommendation is the same as all the others: getting the most out of smart, talented people. A typical day for a developer involves research, planning, documentation, and risk management, and that’s not even including coding. By helping them grow, giving them time to work, asking their opinion more often, and teaching them about your business, you can leverage developers in whole new ways. And make working with you more enjoyable and meaningful as well.
- Don’t leave developers downstream. Involve them early and often during projects.
- Give developers ample time for deep work. And give yourself that time, too.
- Teach developers about your business beyond their limited role.
- Leverage developers more. They are naturally curious, and have worked hard to become problem solvers.
Contact us if you’ve like to work with developers that care about marketing strategy and the growth of your business.