Deep breath

Before you do anything, get yourself to a state in which you can think and act rationally. Go for a walk, play with your dog, have a cocktail, whatever it takes. Only by approaching the problem objectively can you hope to get to the root of the issue and prevent the problem from happening again.

Find out what happened

Most problems with developers come down to a few basic issues:

1. Bad communication in general: read this.
2. Too slow: read this.
3. Inaccurate estimates: read this.
4. Misunderstood requirements: read this.

If you have a problem that doesn't fall in to one of those categories email or tweet me and I'll be happy to help.

Address the issue in writing first

Now that you know what happened and have a working theory of what the problem is, compose an email to the developer in question. Before you start writing, make sure you are not writing in anger or frustration. If you need to, write an angry email, delete it, then start over. No communication at all is better than an email sent in anger. I cannot stress this enough!

Raising the issue in writing first serves a few purposes, the most important of which is that it helps organize your thoughts properly and you can rephrase your statements to sound less like a personal attack.

Email gives your teammate time to process what you're saying without having to respond immediately. When dealing with criticism via a face-to-face or phone conversation peoples' first instinct is to get defensive rather than think carefully about what is being said. Getting the ideas out front in writing helps mitigate this.

At the end of the email suggest a date and time (that isn't immediately!) for an in-person meeting or call to discuss, but do encourage them to share initial thoughts via email if they wish. The goal is to organize both of your thoughts so you can come to the meeting prepared to work out a solution together.

Ask questions

When you finally have a real-time conversation with your teammate, be sure to frame the meeting as being about solving the problem, not criticism or blame laying. You should be asking questions rather than telling the developer what to do or belaboring what went wrong.

It sounds obvious, but your goal here is to suss out potential solutions to the problem. Don't forget to ask your teammate if they have any ideas! You may need to draw them out a little bit by probing deeper in to their answers and asking them to clarify their thinking for you.

Follow up

At the end of the meeting you should have a couple action items for both of you. Set a time to follow up to assess whether these action items have helped or not, perhaps after the next sprint or mid-way through the next project. The key here is to have an ongoing conversation, not one-off criticism sessions.

Keep retention in mind

If you're in a senior leadership role it's important to keep retention in mind. Here's a quick guide on how to keep your developers happy.

Need a hand?

I provide management, full stack development, hiring, and coaching services for startups. Click here to learn more, or schedule a free 30 minute consultation.

Want to go more in-depth?

This article is pretty high-level. If you want more details and tactics on how to deal with developers, sign up to get 50% off my upcoming book, Dealing with Developers.

Questions or comments? Drop me a line at me@jeremyphelps.com or tweet me @remyphelps.