10 Tips on How to Manage Software Developers

Developers and programmers are artists. Smart artists. Professionals. With their egos and ambitions. So managing them is often a challenge, not to mention a team of developers. Having been a project manager and a developer myself, I participate in both worlds and have some tips for you, dear managers and C*Os.

Notice: some of these tips can be applied for general management, not only in software development.

1. Don’t be too bossy

If you try to give a list of requirements to a developer with a context “I don’t care how you do it, I’m your boss and I need you to do this”, quite soon you will receive a resignation letter. Developers (and, frankly, all senior professionals) don’t operate on a basis of “I’m the boss, you’re my employee/slave”.

So be friendly, give the tasks, discuss them, don’t push too much for the urgency — it won’t give results, it will only add stress. Which actually might bring results in short term, but in the long run it will ruin relationship.

2. Don’t tell them how to do their job

This is related to the first tip, but more technical. Don’t ever tell a developer which method/language/framework to use. Most common example is “I need a website with WordPress” from a person who doesn’t even know what WordPress actually is, only heard the keyword somewhere.

Of course, the exception is if you are a developer yourself and can speak the same language. But even then — you need to specify the goal of the task, but it is the developer’s job to make final technological decisions. Otherwise you don’t need a developer, try Code Monkey.

3. Spend your time on preparing the task

Developers are professionals but not magicians. They don’t read your mind. Or client’s mind. They need clear instructions on what needs to be done (remember — what, not how, see above). If you spend some more time on actually writing down the specification or details for the task, it will actually not only save time in the long run, avoiding unnecessary discussions, but also will help to avoid mistakes or misunderstandings on developer side.

Another benefit of having a written task (no matter where — Trello or Google Docs is fine) is that you can both come back to it later and check if you’ve done everything correctly. Trust me, you will forget task details in a month or even a week — this reference guide is amazingly helpful and doesn’t take much time to prepare.

4. Tell them WHY. Give them a mission.

Developers like challenges. No, they LOVE challenges. That’s why events like hackathons are so popular — people gather for 24 or 48 hours and just create awesome projects. So when giving a task to developer, think about it this way — you tell the ultimate goal, and then they decide how to accomplish it effectively.

Not only that — if you tell the reason why you’re building a feature, a developer might change the way of coding it. Quite a lot of technical decisions depend on how this feature would be actually used and what is considered a successful feature.

Another benefit of such discussion is that developer might come up with a different way to approach same function — it might even lead to NOT doing it (which would save you time/money, awesome!). So be prepared to listen to their opinions, developers love to be heard.

5. Be a link between developer and others

To achieve end result, it’s usually more than just developer(s). There are also designers, copywriters, managers and other people. You need to be an interpreter between all of them. Keep in mind that these people speak different languages.

You need to not only deliver/translate messages, but also help in getting necessary information. Quite common example is when a developer is waiting for design files or some clarification from a manager, and the longer is waiting time, the more problems you have for overall project.

6. Be always there, be involved

A lot of managers think that you have to give developer a task and then leave them alone until they ask for attention. That is not true. Constant feedback from management or just random mini-discussions are a great way to stay on track.

Also there’s a psychological part of it — developers like to get attention and be visible, be important. Actually, all people like it. So if you just randomly ask “How’s it going” from time to time — you can get some karma points and additional motivation for developer. Just don’t over-push with those questions — be helpful and friendly, not annoying.

7. Don’t micro-manage

On the other hand, don’t test every step they do. If you try to participate in every decision, discuss every detail or measure their working hours/minutes — you can really easily annoy them. And therefore kill productivity.

There’s a thin line between actively helpful and micro-manager. Think about it from their point of view — would you be angry if your manager was acting like you are now? Also — this can potentially lead to bad micro-climate in the team and hate. As it is said,

“People usually choose jobs because of a company, but they leave because of a manager”.

8. Know their strengths and weaknesses

Software development is a huge thing. There’s mobile, web and other programming “worlds”, and each of them is sub-divided into operating system, front-back-end, and then there are languages/technologies. One just simply cannot be good at them all. So you need to know who is the best person to perform on certain task.

Even within the same task, it sometimes makes sense to divide it into sub-tasks and delegate some separate part to another developer. The goal here is effective overall result, so use your resources wisely.

And remember — if a developer doesn’t know something, it doesn’t automatically make them worse or unprofessional, it just means that they didn’t have experience with something. But they probably are more experienced in other fields. Or willing to quickly learn/adapt — that’s often even more important than knowledge.

9. Learn some development yourself

Your first thought is probably “Seriously??!!” Calm down now, I am not suggesting to go through coding manuals or actually creating some stuff for developers. What you actually need is to understand the terminology, in order to make estimates, to translate developer words for other non-tech colleagues/clients, to make better management decisions yourself.

This is especially useful if you’re a part of hiring process (protip: you should be). If you can distinguish front-end from back-end or understand the difference between CMS and framework, this might come handy once or twice. And it’s not a rocket science — I’ll probably write an article on this particular topic someday.

10. Be a leader, not a manager

As a final tip — gone are the times when managers existed as controlling machines. In 21st century managers need to gain respect of their team, be part of it, and be a helpful and result-oriented person.

You have to lead the developers and make them feel that you’ve got their back. Only in this case they will treat you with respect and will give more effort towards overall result. And this is the ultimate goal, isn’t it?