Whether you’re trying to get the most out of your in-house team or you’ve decided to hire out to a third-party developer, getting the most out of your relationship is essential to completing your projects successfully.
And a big part of that success is about communication. Namely, what you say (or don’t say) to them can mean the difference between getting everything you want or simply getting a door slammed in your face.
So, here’s what you need to know to make every developer adore you.
Do’s and Don’ts for Communication
Sometimes it’s easy to assume that when you say one thing, your dev team is hearing it the way you meant it. But a lot of times, client requests – especially those from non-technical clients – get lost in translation. Here are few ways to tweak your words to make sure you’re understood.
DON’T say: “This isn’t what I wanted”
Here’s the best advice we can give: devs can’t read your mind, so don’t pretend they can. You have to say what you want and say it very clearly. Draw a diagram. Over explain. Don’t treat them like children, obviously, but make sure you can show exactly why you want a project developed the way you do.
Are you trying to meet a certain goal? Do you have a specific target audience you’re trying to reach? Give your devs as much information as you can up front instead of just complaining about the project halfway through. It saves both of you headaches and hassle.
Do say: “This is what I want, and here’s why…”
DON’T say: “I want you to copy this exactly”
As they say, there’s nothing new under the sun. While a lot of what you see out there on the web will follow a basic formula or template, there is some really cool, innovative stuff being created every day by devs all around the world.
If you’re hiring a dev team to build you something amazing, don’t sell yourself short by asking them to carbon copy another site. Take some inspiration, show them some examples, but then step back and give your team some room to run with it.
Do say: “Here are some examples of things I like. How close can you get to this while still being original?”
DON’T say: “Just do it how I asked you to do it”
If, however, you’re not a dev yourself, it’s better to ask what the best solution is to get what you want. Chances are your team has some great experience or recommendations for building the site or app of your dreams.
Do say: “Here is what I would prefer. Is this the best way to build it?”
DON’T say: “Can you get this done faster?”
Everyone loves a panicked time crunch, right? Not so much. Dev teams are notorious for putting in long hours problem solving, so making more demands of their time is the fastest way to get on their grouchy side. If you have a specific timeline in mind, and it needs to be met, then find out what you can do to make the process easier on them.
Do they need your approval on projects quickly? Will they need certain files or content from you in order to move to the next step? Make sure you can keep pace with them so they can keep pace with your deadlines.
Do say: “Here is our projected timeline. What do you need from me to get this done?”
DON’T say: “Here’s my budget, make it work”
Unless you’re Tim Gunn, you probably shouldn’t go around demanding that your team “make it work” if you’re not paying them to work. Your goal here is to hire the best, not the cheapest, because you do ultimately get what you pay for. If you’re on a limited budget, pick one or two projects you know that the team will do exceptionally well, and worry about upgrading the rest as you go.
Do say: “Here is what I want you to focus on, is that doable for now?”
The key to successful communication is to ask questions and be open to suggestions. There’s a level of trust that goes into working with any team. But, the more trust and freedom you give the team, the better they’ll respond (if they’re worth their salt, anyway).
What Devs Really Want You to Know
At the end of the day, devs have your best intentions at heart. If they could tell you anything about working with them, it’d probably be these things:
We really do want your project to succeed. We’re not just here to eat pizza and code. Okay, maybe some of us are, but we like accomplishing things, too.
We’re not designers. Well, sometimes we do both, but most developers just code. If you want both, make sure you ask. Don’t assume we can Photoshop you a pretty picture just because we know HTML (or vice versa).
Source: Zen Freelancing
We want to speak your language, but it can be hard. We’re technical people, and if you’re not, we’ll have to try to explain some complicated terms to you. We’re not always the best at it, but we try.
We’re on a timetable, too. We want to get things done as quickly as you do, but sometimes problems need to be solved or other pieces need to fall into place first. If we’re not getting things done fast enough, there’s probably a legitimate reason.
We want to do cool things. Building websites or apps the way everyone else does pays the bills, sure, but we really want to tackle new and exciting challenges. If you have some cool ideas, throw them our way and we’ll see what we can do.
We hate bugs. Yes, crawly bugs are pretty gross, but so are bugs in our codes – which is why we spend so much time testing and retesting. Websites and apps go through numerous tests, so keep that in mind when making your deadlines.
We don’t mind feedback. Though we should add, “As long as it’s productive.” Feedback can be very helpful, but we often deal with a lot of complexities, so we need that feedback to be as specific as possible. Instead of saying, “No, I don’t like this,” give us a detailed list.
We’re experts, so trust us. We’ve been doing this a long time, and the worst feeling in the world is to think that you’re not confident in what we do. Take a breath, sit back, relax, and trust that we’re going to build you something great.
Working with a team of devs, whether in-house or outsourced, can be a great way to implement some new, creative strategies into your business. But the last thing you want is to stress out the team trying to get things done.
Be sure to communicate as clearly (and as often) as possible. Provide feedback, give us suggestions, and show us what you like (or don’t like). Just make sure that you’re not micromanaging or expecting things to be done at lightning speed.
Give us your timeframe, set expectations, and then sit back and watch us go to work. You’ll be surprised at what we can accomplish when you give us a little room to run.