By Craig Buckler

12 Tips to Help You Communicate with Your Developers

By Craig Buckler

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…

  • John

    I get number 8 often. People often mention number 9 too and will ask for a big project in 5 days.. I usually tell them that I’ll try my best to get it finished by then, but it might take longer (or sooner).

    • Emile

      Point number 8 is the most irritating of all situations. It shows gross arrogance and naivety from the client/manager and it poses the danger to lock you on the PC for far longer than expected.

    • Matt

      I totally agree! I work as a developer in a marketing company, so almost none of them understand how much work things take. After they over promise to clients, I sometimes have to break the bad news that it’s not possible on their shoestring budget.

  • Gavin

    Thanks. I’m really glad I got past the title and read this.
    I had initially judged the title to mean ‘How to deal with your oddball developer’ and was slightly offended, but having read it I’m delighted that it attempts to put some project responsibility back with the business owner.
    Having not yet developed my telepathy skills, I’ve personally experienced most of these problems first hand and in most cases it was implied that they were my problems as I was, ‘The developer/designer/marketeer/copywriter/tester/SEO’er/IT person’.

    • Thanks Gavin. Never judge a blog post by its title!

  • MightyTrashCan

    7,8, 9 are what I most commonly face. Often the client or manager would say that in a previous project, my developers did request X in a few hours!

    But what they may have forgotten to consider is that feature may be quickly implemented thanks to a ready made plugin for a particular CMS and there is also a need to take into account of developer skills too. Programmers, despite their names, are humans too and their abilities varies.

    For 9, well this is an irony I sometime faces, I would be asked to give a dateline, but everytime I gave a dateline, the next reply was “So long?”, that pretty much make it pointless to ask me for a estimated date.

    • chp

      Your last sentences should be printed on every wall in every office,

  • Tom

    I agreed with all of these, but also found myself thinking “How DARE he say that out loud” in the back of my mind. Am I schizophrenic?

  • Mark

    Good tips. Spoken like a true developer. I imagine you have experience as a software programmer. :)


  • Pascal

    This post is really, really important for project managers/owners. there is no single point that aint encounter. believe me, each point upsets me equally and I realized that if I am un-productive, its because of one of those 12 points stated above. I really appreciated your article. I will spread it through my facebook and linkedin, so that it can help others(especially managers) as well.

  • Darren

    Number 7 is our worst problem. Also when people try to treat a programming project the same as a design project.

  • Wolf_22

    “…that’s what she said!” ;)

  • Edwin

    # 7 – Scope creep is something that we really try to work on in our process, but no matter how detailed we are, the scope creep seems to some how always find it’s way into projects.

    Project Managers and Designers and Developers need to part of every kick-off call, as well as the initial specification document, this way the team can weigh in on “red flags” together.

    Good article!

  • Transio

    I can’t figure out who this article is supposed to be for…

    If you’re a company with your own developers (as the language of this article implies is the case its addressing), then you should also have a PM who specializes in management of software development. If you don’t, you’ve made a serious error in judgement and should fire yourself.

    If you’re a client looking for someone to develop your application for you, you should hire a company that’s organized, experienced and reputable enough to know exactly how to manage you and your needs, ask you the right questions, and handle all of the issues in the above article internally.

    If you’re something else… say a designer outsourcing a project or a client working with a freelance programmer… then the above article fails to emphasize the most important things for a non-techie in dealing with a developer… wireframes and flow diagrams. These shouldn’t be off-handed remarks in 1/12th of the bullet points… they should be the entire focus of the article. These are your ONLY tools for communicating your idea in precise, concrete terms to your developer in a language you both share. You should have wireframes and flow diagrams for EVERY PROCESS in your web application. NO EXCEPTIONS. These should be the entirety of your specifications / design documents, with the exception of any design mock-ups, written specifications of algorithms or general purpose of the application, or other pertinent items that may apply to your project.


    • Are you saying that, as a developer, you’ve never experienced any of these problems? Or, do you work with developers who are never exposed to them? Either way, I’d love to work where you do!

      These are general project issues regularly inflicted by business owners, PMs, clients, designers, and anyone else who has direct contact with a developer.

      • Transio

        I’m saying that as a Developer, I never experienced these issues, because the scope, timeline, and specifications were always created by a single individual (a technical PM) with enough insight into the process and wherewithal to do his job properly.

        And as a Business Owner, I’ve never experienced these issues, because having absorbed the knowledge of a good PM, I know how to properly prepare and manage a team. While your suggestions are a start, there are a couple of important items missing – e.g.

        1. The necessity of technical expertise in development of design documents / specifications, and in creation of estimates

        2. The use of time tracking tools and software project management tools (e.g. Jira Studio or MS Project) to map out your development timeline (in a gantt chart with predecessors, resource tracking, etc…) and track progress / update expectations on a daily basis.

        3. Post-project resource efficiency measurement to determine estimate accuracy and use this information adjust your estimates on future projects.

        With time, using the above 3 tools, you can have near 100% accuracy on project estimates without playing a “guessing game”.

        Yes, you hint at problems and guess at solutions, but you use anecdotal solutions that have worked for you, and you don’t provide real tools and strategies for people to use to solve their problems.

        Your entire article suffers from this type of pedestrian advice… let’s move on to “Test Your Own Application”. This is WAY off base… what a waste of time for a Business Owner or Project Manager! Assuming potentially endless rounds of revisions and bug fixes, you could spend your entire life testing apps!

        Instead, have a QA Professional prepare a WRITTEN TEST PLAN based on the initial design documents (specifications), and execute that plan, logging idiosyncrasies and exceptions in a bug tracking tool (or spreadsheet). Spend 15 minutes reviewing the bugs, and assign them as tasks to your development team (or adjust the testing plan to eliminate known / expected idiosyncrasies / deviations from the specs).

        Now that you have a Test PLAN, when you’re through QA, you can move to Beta and pass that plan to a slew of Beta Testers. Now you’ve exponentially increased your QA accuracy and efficiency while simultaneously eliminating that responsibility from your plate and giving yourself more time to do what a Business Owner should do (Biz Dev, M&A, Partnerships, or for smaller businesses: HR, Accounting, Marketing, Sales, Operations, etc.)

        These are tried and true techniques for professional application development that are known to work.

      • Wow. I definitely want to work where you do!

        I totally agree with what you’re saying — few developers wouldn’t. But best practice techniques don’t stop people being people. Or idiots being idiots.

        I’m a little dubious about your claim of never encountering any of these issues. It’s not the experience of most people commenting here. Were you a developer for long?

      • Transio

        Yes, I was (have been) a developer for over 10 years – first at a SoftBank-funded web startup, then a Commercial-Grade and Enterprise Software development company, an International Services Company with 1000s of employees, serving Fortune 500 Clients, for a few years running my own business, and now CTO of a publicly-traded company.

    • Alderan

      I second Craig on this. If we all worked in an ideal situation as Transio apparently does, we wouldn’t have to worry about any of this.
      Personally, I have worked as both a developer and project manager for 10+ years, and have never had that type of situation.

      Most real-world projects will not have the funding, schedule, or resources to avoid all of these pitfalls. For example: dedicated QA, any non-free project management software, and post-project analysis are luxuries I have rarely encountered. Just because doing it a certain way works better, doesn’t mean I have people lining up to pay for it!

      Good article Craig

      • Anonymous

        I may work in a close-to-ideal situation, but that doesn’t mean it should be ignored when considering less-than-ideal scenarios… instead, it should be used as a basis for creating a plan that would maximize the efficiency of a small business owner. Remember, I was one for a while, so I know what it’s like.

        Can’t afford a dedicated PM? Fine, then learn their tools and take on that effort yourself. I used to split my time 50/50 – mornings went towards biz dev, financials, and client management, afternoons went towards PM and assistance with production. It worked well.

        Can’t afford a QA team? Fine, but that doesn’t mean you should do all testing yourself. Spend a couple hours writing a testing plan and hire a $8/hr student (or free intern) to execute it for you.

      • I assume this was from Transio?

        No one’s saying that you shouldn’t have a PM, QA team, or use best practices. But none of it prevents people using their position of authority to make stupid development decisions! I’ve worked with some excellent PMs but, ultimately, they succumb to the person who pays their wages.

        Perhaps you’ve never experienced these issues because you worked for large corporations with long-term plans and slower decision-making processes? In smaller organizations, it’s not uncommon for clients or CEOs to request a feature on a whim.

  • Gozie

    I sincerely love this writeup. I am better equipped to communicate my developers now. Thanks SitePoint.

  • chp

    Quote: They probably look odd and speak a weird language.
    The first is a overused cliche & the second is – at least in professional business – untrue:
    I get Point 1 a lot as well as 8. If someones coming to me, saying “it needs to be just like Facebook, only — er — like, different”; he’s definitely not in the position to call our language weird!
    I work in an agency. We do not have Projects around 1600 Days, we have very much projects with 30 to 50 days schedule. Our sales department often makes the following assumption:
    * We have made X in Y days and Z is similar.
    * We can’t go down with the day rates, ’cause it’s the first project and we don’t want to establish cheap. Thus, we have to decrease the days. Oh look, there’s feature X (substitute feature X for a build in Feature in a CMS like Drupal, that takes minutes to implement)! Why don’t we kick that and discard 10 days?
    There are many clients they are dealing with and it’s not possible to go with them after the first cold call every time.
    I want to say a simple truth: Distributing software is completely different than selling products (with an established build process), yet very few of the salesman know that.
    And to be arrogant on the last: As a developer, you have a very clear concept about what the salesman is doing in his business, but he has none about yours.

    • Gobbag

      Give the guy a break for using an overused cliche to get you reading! besides, like most cliches, there’s some truth in it – I can say that, I’m a developer ;-)

      Don’t get me started on testers…

  • MTC

    just to point out, there r also managers who believe things should be done as long as it’s technically possible. I once worked with a designer who was so attentive to detail. He even wanted to style every single title and header uniquely. That was certainly possible but really bad for the separation of content and style (imagine adding br or span tags to every blog post title and each are somewhat similar yet different from another).

    I failed however as the manager was on his side, saying “branding” is important.

    I personally feel it’s best if manager, designers.etc all had a little technical knowledge & understands that there r many variables involved. but that probably a pipe dream.

  • Razia

    Nothing to say more. Excellent article! :)

  • AnilG

    I still can’t believe it when I get #8, but I do. I’ve even had a PM start to argue with me (incorrectly) on the technical point I was making. Erm, excuse me, I’m the developer?

    It’s great to see #10 put up there. I so much want to stay in schedule that I need to remember #10 myself. Development is like that. You encounter something mid way that was not understood or known when the schedule was drawn up. Developers need to be allowed to say “this cropped up, it took an extra two days”! We should feel good that we fixed it in only an extra two days!

    #9 is the biggest problem. “There’s never time to do it right but there’s always time to do it over”. If your schedule is too tight from the beginning, problems WILL occur and it will take LONGER than if you scheduled it right in the first place.

    I also need to remember #9 myself. As a developer trying to please management I do tend to offer optimistic schedules. It gives a bad impression and doesn’t help. Developers: give yourself the time you need! Programming is complex, involved, and labour intensive. Even geniuses need the time to build the miracle.

    Thanks for your support, Craig!

  • Flopy

    Thanks so much for that article. It does highlight a lot of truths about how life goes in a real-life organisation. I work in a museum, we’ve got a small development team, no business analysts, testers, or anything of the sort, and a very low level of awareness throughout our business when it comes to technology, so I can say that I’ve experienced points 1 to 12.

    That being said, I’m in a weird situation. I am not a developer, and usually act as the interface between our business owners and our developers, to get decent requirements out of the former. I’ll often be the one drawing what things will look like.

    I’ve always been wondering if I’m in the way of the business owner, and if, because I’m there, they would be losing that sense of ownership they might otherwise get. Has anyone had a similar experience?

  • Dan

    Thanks. I learned more from “Discovering Real Business Requirements for Software Project Success” by Robin F. Goldsmith. I recommend it especially if you are working with people who take the whole process too lightly.

Get the latest in Entrepreneur, once a week, for free.