12 Tips to Help You Communicate with Your Developers

As an internet business owner you’ll need to face your developers. Yes, it’s scary — they probably look odd and speak a weird language. But you can’t avoid it. Here are my 12 tips to help you communicate with your development team…

1. Know Your Requirements…

How can you explain your requirements if you don’t know what they are? Developers are often faced with vague, wishy-washy briefs such as “it needs to be just like Facebook, only — er — like, different”. A good developer will immediately begin to analyze your idea. They’ll ask questions. They’ll pose “what-if” scenarios. No one will expect you to have all the answers, but you should be able to discuss the majority of problems. If you can’t, you haven’t thought the project through. It’ll fail.

2. …and Document Them

Putting your requirements on paper may not be fun, but it’s necessary. Interface sketches and flowcharts will help you identify functionality, understand the technicalities and explain issues. Consider hiring a systems analyst if you can’t do this yourself. They’ll ask identical questions, though.

3. Don’t Use Pseudo Code

If you’re not a programmer, please, please don’t attempt to write pseudo code — it won’t help. You’ll almost certainly over-complicate the easy stuff and gloss over the complexities. Your developer will need to reverse engineer your ‘code’ to determine what you actually wanted to achieve. Pseudo code is useful when developers discuss algorithms with each other. There are few other reasons to use it.

4. Agile Programming is Not an Excuse for Poor Planning

Don’t think that rapid, agile software development excuses requirements analysis. It may reduce some of the up-front planning, but you’ll still need to make just as many decisions — if not more.

5. Be Clear and Decisive

Programmers make thousands of decisions on your behalf. However, they will inevitably have questions during the development process and failing to providing a definitive answer will halt progress. As good manager, you’ll take responsibility, make a prompt decision, stick with it, and face the consequences if it’s wrong. Bad managers are unavailable, avoid answering the question, seek opinions from 57 other (disinterested) colleagues, then blame the developer for delays or bad decisions.

6. Stay Ahead of Your Developers

Good programming teams will have a development plan — components and features will be implemented in order. Understand that plan and prepare accordingly:

• know what decisions need to be made prior to implementation
• prepare dummy data or test cases
• organize the production of content, graphics, videos or other media.

7. Avoid Scope Changes

Changing scope can destroy a project and put a deadline at risk. You may have seen a cool feature elsewhere, but it doesn’t need to be implemented immediately. By all means, have an informal discussion with your developer. State it’s something you’re considering for a later version — don’t distract them from the agreed tasks or demand immediate attention.

8. Don’t Assume Anything

One of the worst statements made by non-developers is: “Hey, we should implement feature X. It’s easy, right — it’ll only take a few hours.” It might take a few minutes. It might take months. It might be impractical. It might be technically impossible. You don’t know — if you did, you wouldn’t require a developer to implement it for you.

9. Set Realistic Deadlines

Like anyone, developers work best when they have an agreed deadline. However, those deadlines should be set by the developer themselves or someone with programming abilities and in-depth technical knowledge of the system. Setting an arbitrary or unrealistic deadline will result in a bug-ridden monstrosity which takes far longer to fix.

10. Alter Your Schedule When Necessary

Application development is complex. Development estimates are just that — estimates. Programmers will encounter unforeseen problems and changes to the project scope (no matter how hard you try to avoid them). The schedule will inevitably change as the project progresses. Do not be afraid to modify the completion date accordingly.

11. Test Your Own Application

Don’t rely on your developers or other people to test your application. It’s your vision: test it yourself at every opportunity. That said, be aware you may be running unfinished code and check progress against the development schedule. Don’t send emails ranting about feature Y not working when that code hasn’t been started.

12. Stay Involved and Keep Communicating

Most people lose interest in their own projects as time goes on. If you can’t remain enthusiastic, don’t expect it from others. Contact your developers on a regular basis. You don’t necessarily need to organize formal progress meetings — just show your face and ask how things are going. That said, avoid pestering them. Your project won’t be completed quicker if you call your developer every 10 minutes to ask “are we there yet?” Let your developer do their job. Do you have any developer communication tips? Do you have first-hand experience of bad management? Comments welcome…

Frequently Asked Questions (FAQs) on Better Developer Communication