How to talk to your Dev?

Business Learnings

9th June 2021

Communication between client and developer can be one of the most challenging aspects of the tech world. There are lessons to be learned on both sides.

The bright-eyed business people come in with an idea only to be met by a furrowed brow developer. It’s nothing personal. You have to understand that when you’re explaining what you want, developers are trying to translate your idea into their “fancy computer language” (a technical term), figuring out how to make it happen or if it’s even possible.

This disconnect can end with frustration for developer and client.

The good thing is it doesn’t have to be this way. Learning how to communicate with your developers goes a long way to getting your project off the ground. It’ll save you time, money, you’ll end up with a better final product, and you’ll have a better experience along the way.

Cool cat

End-users have to understand that developers are not trying to be difficult, and they’re not always at fault when issues occur. Software development is challenging, unforeseen problems arise, and bugs are just a part of the process.

Although we’re focusing here on how end users can learn to communicate with developers, this is clearly a two-way situation. There is also an onus on developers to understand the end-user and final UX.

Developers are inherently logical creatures. They have years of experience tricking transistors into building the modern world we all enjoy, but that experience doesn’t always translate to great communication skills. Good developers have to be a little empathic with their clients, and when they can’t, they have to know how to ask critical questions that get them closer to the client’s solution.

At the end of the day, both parties want the same thing. To seamlessly marry the client’s idea with the developer’s coding, the key to succeeding is healthy communication.

Step Brothers Ryan GIF


Top Tips for healthy dev communication

  • Understand what and when you’re asking

    Problems occur when clients ask for a change or new functionality during the project. It comes from the disconnect between the clients’ perceived difficulty of the request and the actual difficulty of what they are asking.

    We all interact with tech daily, and there is a good chance you have some knowledge on the subject. “It’s just a small change”, “How hard can it be?”, but assumptions like this lead to considerable frustration on the developer’s side.

    In some ways, it is understandable, unless you get into the nitty-gritty of development; the difference between a simple change and a complete overhaul of the codebase can seem pretty arbitrary. 

    A slight change from the client’s POV can take weeks to implement. Conversely, what the client may consider a huge change in project scope might only require a tiny tweak.

    The key lesson to remember is that: no matter how much you know about the subject, communicate with your developer team first.

    The worst-case scenario for developers is the dreaded late project change. The first step in the development process is to map out the underlying architecture of the project. All the coding that follows depends on this architecture. What seems like a small change to you has the potential to render the original architecture inefficient or, in dire situations, require a complete overhaul.

  • Learn basics of software development

    No one is expecting you to become an expert coder. If you did, you wouldn’t need to communicate with developers in the first place. But if you’re working extensively with developers, grasping some basics goes a long way. Even just understanding the lexicon of developers can make a real difference.

    Know your front from your back end; what’s this stack they keep talking about? Learning the bullet point version of the key concepts takes your communication to the next level. Developers can seem like they have a magic box pumping out apps and websites. By taking a bit of time to learn the basics, you at least get a window to glimpse inside the box. 

    And really: there are no stupid questions in development, don’t be shy to ask!

  • Context is everything

    Clients typically come to the project from the UX side, how people are going to interact with the product and what their needs are. When describing this to your dev team, it is important to explain every aspect of your vision. The context of the final product is everything. Even functionality you may think is self-evident has to be clearly communicated from the beginning. Leaving out context can end up with work that doesn’t match your needs. Plus if your developer knows what outcome you want, they might surprise you and suggest an even better/cheaper/easier method of getting there!

  • Two-way communication

    Listening to the feedback developers give is vital, especially at the beginning, when defining the project. You can dream big, but they are the ones who are going to have to make it a reality. It’s better to listen early and understand what is possible and what isn’t within the project constraints. They say “perfect is the enemy of good”, having a smaller project outcome is better than the perfect one that never sees the day of light!

  • Timeframes can be misleading

    There is a vast range of experience and ability when it comes to developers. A developer who can fix a problem in 5 minutes, that would take others considerably longer, spent years working hard to get to that point. So if you think you are being charged a lot, consider that you are also paying for the work to be done that quick. Another thing to keep in mind when it comes to timeframes is that a 5 minute fix may take weeks to reach the client. There are different levels of importance to developers’ work. Changing a font size will likely stay below rescuing a collapsed server on the to-do list.

Bug reporting with devs in mind

Something that is easy to fix and leads to a significantly better experience for both client and developer is understanding how to report bugs properly.

“X doesn’t work” is extremely unhelpful for the developer who picks up that ticket. Debugging can be like finding a needle in a haystack. Giving additional information allows the developer to focus on a corner of the haystack. Otherwise you might end up in a heated ‘But it works for me’ scenario that is frustrating for everyone!

Here is the key information to provide when reporting a bug:

  • Clearly define the problem (what happens vs. what you expect to happen),
  • Try to recreate the bug, and describe step by step how it’s done. Screenshots, urls or videos are always helpful
  • Provide as much context as possible (What device are you on? What operating system are you using? Do you get an error message? What does it say? What browser and which browser version are you using?)
  • Stick to one bug per report

If you follow these steps you’ll be dealing with a thankful developer and your bug will be fixed in a fraction of the time.

Telescopic Devs

At Telescopic, we hire developers that are also great communicators. They’re a rare breed, but we see firsthand the difference it makes for our clients and us.

Get in touch about your project today and put our communication skills to the test.

Back to News