What to do when my Developer Doesn’t Speak My Language?
First, some assumptions:
- You are working with a competent developer or team
- You have an agreement that is beneficial and flexible for both parties
- You are interested in continuing the relationship you’ve built
OK, with those assumptions out of the way, we can talk about how to communicate with developers. There are four things you should do when communication becomes difficult, and you just aren’t on the same page.
1. You do not speak the same language so don’t assume
You and your developer do not think the same way. The developer that you are working with is hopefully a competent, intelligent person. EVERY developer I’ve met is slightly contrarian and does not fit into the mold of a follower. Part of this is because they have had to figure out where they fit in society for a long time and because they are being paid to solve problems. So asking a developer just to do what they are told is at the very least a waste of your money and at worst being a bully.
Consider starting the exploration over again. Not the whole discovery, but engage with the developer to “start over” and look at the problem to see how you both came to different conclusions about where you are. I’ve found that this can be useful for identifying problem areas and understanding how to get back on the same page.
2. You have different clocks
Developers operate on production time, not management time. The WORST thing you can do is expect an answer RIGHT NOW. They might be in a completely different brain space if you press an issue when they are not prepared. For instance, if you lean over her monitor to ask her a question about something that doesn’t seem right. That brilliant solution that she was working is gone now.
Politely ask for a time to review if it’s not already scheduled. But be patient and respectful. Just taking a moment to ask permission to engage in a conversation will do WONDERS for morale. As a manager, your time is measured very differently. You might think in tasks and 15-minute increments. For a developer, they need time. Lot’s of it. Uninterrupted.
3. Use pictures
Your wire-frames are crucial. Even just a sketch can make a huge difference. You probably don’t REALLY care about the code, and that is fine. So if you can use pictures to describe the problem and what you want to see, I know you will get a different result. And use a big pen. Don’t get lost in the details. Use a giant marker to explain the problem in as little detail as possible. I’m not kidding. Find the biggest marker you can. Let her wrestle with the problem and work with you to develop a solution.
4. Stay humble
Developers know more than you do about the tools that they use. Otherwise, you’d be doing it! So stay humble and understand that what you think makes sense may make NO sense in light of what the developer is trying to do for you. Give them space to breathe and come up with an answer. I’m usually a fan of restraints, but restraints that are arbitrary can do harm.
With those four ideas, I’ve seen potential disasters averted and turned into successful projects. Being on the same page is crucial, but speaking the same language is not. You can overcome a perceived deficit and create awesome products with a little developer management.
Join the Conversation
This is the from the archive of an ongoing series called Making Things That Matter. Each week I will send you an email with another step in the process of building products and launching ideas. Signup here to join the conversation.
