Now, before we get into it, no, I’m not about to talk about a methodology for effectively working with Developers in product teams - because people aren’t processes, nor should we treat them like they are. So, if you’re here for that kind of content, you’ve come to the wrong place.

Now that I’ve cleared that up let’s get started…

Once upon a time, I had a Product Manager friend, and we had a sneaky little in-joke together - and that was that we were both Dev whisperers. We were both convinced that we could get any Developer to align with our thinking and work on what we wanted. This had been an ongoing theme over our career, where we saw others struggle to get alignment and, as a result, fail to ship their proposed products and features.

Before I come off as a manipulative arsehole who gets people to do what I want, let me clarify. There was no planning, scheming, or hidden agenda in our day-to-day jobs to do this - I have always just worked incredibly well with Developers. I could never really put my finger on why - despite feeling like it was the secret sauce for the perfect product team that everybody would want to get their hands on that I desperately wanted to understand and share.

It was only after a few years when I reflected on my career, that I finally understood. To explain this, I need to lead with a story of a time when I worked with a Creative Director that shall remain nameless (because frankly, and thankfully, I have since forgotten it), but in the interest of this story, we’ll call him Tom.

I never felt Tom liked Developers; I always thought he genuinely hated working with them. Every day, he would bicker and moan about how lazy and stupid our Dev team was. And he felt entitled to that opinion - after all, he worked so hard on revolutionary, innovative, and cutting-edge projects. How dare our Dev team tell him that his multiple interactions, animations, and advanced features would take months beyond the allocated scope to build because the tech wasn’t there to support them.

As a result, when he was told this, he called them liars, bitched at the CEO, who would then yell at them. He would then go back into his little corner when he realised he couldn’t do anything more about it, stewing in his resentment even further.

I was also at this company and worked with these same Developers, but I had a very different experience. This group of exceptionally kind and talented people was overworked and seen as a feature factory constantly being told what to do without ever being part of the process. They were never asked why, they were never brought on the design journey, and by the time they explained why they couldn’t build it, it was too late in the process and they had been written off.

While this was a more extreme case, these interactions are sadly not uncommon in the tech industry.

It took me far too long to realise that it all boiled down to three simple things - collaboration, communication and respect.

Collaboration

Teamwork makes the…

Please don’t make me finish that saying. Despite how cringeworthy it is, there is some serious truth to those words. In my story, Tom never collaborated or spoke to the Developers, he designed in a silo and tried to hand over his work when he was done.

Collaboration allows us to align, understand and evolve our work in a feasible way. It gives everyone an opportunity to be involved in the creative process, creating stronger buy-in and reducing the risk of bloating the scope beyond reason.

Don’t forget, it’s not you vs. them - you’re literally on the same team, with the same goals and ideally, similar values. You’d be surprised at how much Developers would care about your project if you involved them early and often.

Let’s talk about the ‘handover’

The term handover seems to have taken on a new meaning, now being the point at which we involve our Developers with our work.

While you should definitely put together a spec doc and do a spec walkthrough with your team, none of this work should come as any surprise to anyone. A handover should be just that, the point at which you give your Developers a detailed spec to start building, certainly not when you first involve them.

If you make changes after giving your Developers a spec doc, be sure to tell them and explain why. Mysterious changes in a file will get missed, they’re’ also incredibly annoying to those working on your projects.

Communication

Do it often and keep it open

Creating a consistent and open communication channel in your team allows you to learn and grow as a team continuously. It’ll create a safe space for Designers and Developers to share thoughts and ideas.

Doing this will improve not only your product and designs but also your day-to-day working life. These are the people you interact with for almost a third of your time - make it a happy experience.

Listen and learn

Start giving Developers more credit, they know a lot more about implementation and accessibility issues and opportunities. Including things that you likely would have never even considered. I’ve run many design crits with Developers who were more engaged than the Designers and had more constructive feedback than anyone else in the room.

This is because their job is to understand everything there is to know about technical setup and limitations, as well as overcoming them. They don’t start and end their day just staring at code - well… none the less, they are creative problem solvers, just like Designers.

Listen to what they say, and maybe you’ll learn something. Trust me, having strong development knowledge on a product team is a skill you want.

Be sure to make a continued effort to understand those you work with, which will help you develop continued respect for one another. Because, we all know, we don’t listen or trust those we don’t respect.

Respect

Put in the work

Sometimes it can be difficult to work with some people, especially if there are personality clashes, making it hard to maintain respect for your teammates when you just want to yell at them constantly.

And yes, hard conversations suck, it’s easy to ignore things when they get difficult. But having hard, constructive conversations also helps us develop a stronger understanding and empathy for others - they also help us develop that respect that will allow us to freely communicate, collaborate and listen (see what I did there).

Compromise

Finally, once you’re collaborating, listening and respecting one another, you’ll also learn when to compromise on designs and ideas. When teams are aligned on the goals of the project and the overall vision, everyone will work to try and fulfil that, even if that means pivoting from the original idea to get something shipped.

If Tom had followed these tips maybe he would have gotten to a solution that was almost just as revolutionary as he had designed, who knows, it probably would have been even better.

Before I sign off, yes, people will always be difficult to work with. But, if you’re finding that everyone is challenging to work with, maybe consider for a moment that it might be you.

Don’t be a Tom, be a Steve.

Be a Steve