Getting the most out of a developer

I’m a front end developer who has worked in corporate software companies and agencies for nearly 7 years. While my character as a professional has stayed the same throughout, my personality has undergone huge changes as I worked with teams and bosses of separate nature. Over time, I realised what was in some teams that made me more productive than others.

Treat each member as equal

No two members in a team are the same. Someone would be more productive, someone more effective, someone fast, someone more tenured. They are all on the team for a reason. Don’t discriminate in how you treat them. Don’t encourage patronising behaviour, which the experienced members of the team often are. Let every team member review pull requests, hear out the approach of a newcomer. Embed this culture of equality in the team, be inclusive.

Find ways to keep them self motivated

Everyone has a different reason to be motivated. Of course, it is very difficult for a lead to make personal adjustments to every team member. But at least ensure that you are not stepping on their motivation. I knew a developer that started work at 2 in the noon, but do an absolute kickass job in what he was doing. If there is something that makes a developer productive, without it being a huge problem to the project, make it happen. It’s a small investment and will pay off. Keep them self motivated. It is human nature to perform well when internally motivated.

Appreciate and recognise them

If they did a good job on something, appreciate them, possibly in front of the entire team. If someone has been consistently doing good job, recognise them in a more formal manner (in the form of an award, cash prize, etc). It will keep them motivated and inspire others to be more creative and productive.

Trust

Trust is hard to build and often takes a lot of time to establish. But, by default, trust the developer. Don’t doubt their integrity. There will always be some situation where it would look like may be he didn’t want to do the job at hand. Unless you have solid evidence that they didn’t want to do it, don’t believe it. It’s important to not believe it, not just show that you don’t believe it. A relationship of trust and respect can make a developer much more responsible than the use of power and authority.

Minimise meetings

In my experience, a lot of managers set too many meetings to track the work that their reportees are doing. Blocking a time for something builds mental pressure in their heads and causes distraction. If most of the work is already planned, getting updates in a morning standup call is usually enough. The conversation can often flow into detail for a certain piece of work, this should always be deferred to after the standup with only the relevant people made to attend.

Don’t nitpick their work

Experienced developers often get nit-picky in the work of their junior counterparts. Software development is an extremely creative job, and each individual writes different code. This does not necessarily mean they are wrong. Sometimes, one approach is better than others. In such cases goal should always be to explain the pros and cons of the approach, rather than attacking the person with a separate/new perspective.

Use pull requests as a medium to discuss/share feedback, best practices rather than preaching a certain way to do things.