When working with developers – whether as a client, business owner, project manager, designer, or any other role which affords you direct contact – it’s important to make sure you are communicating effectively to guarantee the right outcome and a smooth journey towards this goal. Here are 7 tips to improve communication with developers, make sure you’re all on the same page and avoid common pitfalls:
1. Determine Ownership and Responsibility
Make sure the developers you are working with know what your role is in the project or work item that you’ll be working on together. Letting them know things like who you report to, what expectations have been set regarding your involvement in the project, and who ultimately owns the project will help to give them context. This context will help create a shared perspective on the project and who needs to worry about each item. This will also help ensure that nothing falls through the cracks due to incorrect assumptions of others’ ownership and responsibility of project requirements.
2. Establish Trust
Get acquainted with your developer coworkers! You may not have had occasion to work with them before. Consider that they may know very little of the current department initiatives and goals against which they are arduously doing development of individual tasks. When you can, give greater context of the reason for the work – this will help to establish trust. Also, take the time to acknowledge any of your missteps during the course of the project, including how these impact developers. This will help others recognize that you take responsibility for your actions and it will help reestablish trust.
3. Know and Document Your Requirements
It’s crucial to know what your requirements are and document them clearly and unambiguously. This is necessary both for articulating your desired outcome, and so you have a record of each item as it relates to the project goals, to which you can refer when evaluating the output. Interface sketches, flowcharts, detailed user stories, wireframes and design mock-ups can all be useful to present these requirements in. Also consider that a well-labeled visual representation is sometimes clearer than a written description.
When you hand off your documents to the developers, it’s best to discuss these in person or on a call as part of a briefing process. Be prepared to explain the intention behind the decisions you have made and answer any follow-up questions. If, as a result of this handoff process, anything changes in the scope or requirements, update the documentation accordingly so you’re always working off the most up-to-date version.
4. Choose Your Words Carefully
Here, clarity is the key. Make sure to communicate in plain, unambiguous terms. Be wary of using jargon, as the terminology can mean different things to different people. It can be tempting to use code to explain specifically how a project or task should be developed if you have some know-how, but only do this if you are confident that you are conversant in the particular language the developers will be using for this specific project. Doing this incorrectly can do more harm than good, and also undermine your credibility in the working relationship.
5. Set Realistic Deadlines, Including a Feedback Schedule
Deadlines need to be set with development sign-off; there’s no point in trying to impose an unfeasible timeline without consulting the developers, as it will most likely result in a project delivered behind schedule and an alienated development team. Agree on a realistic timeline together and map it out using time tracking and software project management tools. Build in enough time for an appropriate number of feedback rounds and QA, and track progress on a frequent basis, communicating this with all team members who need to be updated. Lead by example by completing your own tasks on time if you expect the development team to do likewise.
6. Watch out for Scope Creep
Part of knowing your requirements well involves being confident that you have fully specified all the features and functionality you want. During the briefing process, it is possible that these may change slightly due to technical restrictions or other considerations. However, after this point – when deadlines have been set and development is underway – additional feature requests put pressure on the developers, and may not be feasible within the agreed-upon timelines. When possible, save additional feature requests for future releases, but if something crops up that is absolutely essential, negotiate this with the developers and discuss whether it is possible to stick with the original timeline or if an extension is necessary (or if other parts of the project can be dropped to make way for the new requests).
Be aware that moving the goalposts mid-way through a project is very frustrating, so understanding and awareness of this fact may help maintain the trust that could be eroded through last-minute requests, especially if they are due to oversights or poor planning on your part (as mentioned before, humble tone helps here!).
7. Stay Involved and Keep Communicating Clearly
Finally, make sure you are available throughout for communication and clarification. Find out what format the developers prefer to receive feedback in and adopt those methods. When asking for changes, clearly state what you want if you know it, e.g. ‘Increase the header font size to 11pt’. If you are unsure of the change that’s needed, explain the goal that needs to be reached and ask for suggested solutions to discuss together, e.g. ‘The video needs to be more prominent, what can we do with the rest of the content on the page to make this happen?’. If you are involved in testing and QA, fully document any bugs you find, take screen shots and explain what the change should be (and be sure you know the difference between bugs and feature suggestions!). Whilst documentation throughout is very important, sometimes there is nothing more effective than a quick chat or phone call to discuss, so take advantage of these opportunities as they arise.
These seven tips can help you improve your communication with developers and avoid project disasters. What other strategies have you found successful?
