Project Management

4 Questions You Should Never Ask a Developer

Developers and project managers are sometimes locked into a love-hate relationship with one another. Both have logical and calculated jobs that are meticulous in the actual work, but getting the two groups to work together isn’t always as black and white. Sometimes project managers need to know what not to say as much as what to say to developers. In an article for the Digital Project Manager, Kelly Suter says some questions that project managers need to avoid asking:

  1. “This should only take about five minutes, right?”
  2. “How should I have known?”
  3. “Did you see that email?”
  4. “Can you work an hour on each of these clients today, so we can see progress happening for all of them?”

Question to Quit Asking

When talking to developers on time estimates, make sure you give proper context for your developers when they give you their estimates. It may be tempting to go with the low-ball number here, but you should instead work with the developer with a good/better/best model when working within a strict budget. Good is within budget, but not at full functionality. Better is over budget, but with increased functionality. And best is way over budget, but at full functionality.

If there are areas of a project that are ambiguous and lead to issues later down the line, it’s important to not focus on blame. Avoid asking how you should have known or that it’s beyond your position. The client will not care who is to blame or why, so focus on working with the developer to push progress forward.

Suter continues to explain how relaying client communications to developers is a double-edged sword, as these are your two options:

  • Gather client correspondence, touch base with the appropriate developer (which requires finding time with the appropriate developer, who would naturally rather be developing), transcribe their feedback to aforementioned client correspondence, reply to client with transcribed feedback from developer, and repeat. OR…
  • Interrupt the developer’s coding time and have them follow up directly to the client. While this saves budget and is more efficient, you’re disrupting their production time, therefore causing inefficiencies with development.

This situation is a lesser-of-two-evils scenario, but there are ways to work around it. Suter says to at least confirm with clients that you received the communication and that you will relay it to the developer who can best respond as soon as a reasonable pausing point is reached. It might be even more efficient to set up a system where developers are expected to spend the beginning portion of their day responding to client communications, thus instilling a schedule into communication cycles.

Lastly, when asking a developer to work with clients, it’s a terrible idea to expect them to bounce back and forth between helping several different ones at the same time. Multitasking is a sure way to ruin productivity, so that developers do not ultimately help anybody at all. Make clients wait their turn.

You can view the original post here:

Austin J. Gruver

Austin is a Staff Writer for AITS. He has a background in professional writing from York College.

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.