Not a developer yourself, but ended up in charge of a bunch of them? This is a common conundrum, and also how the scene is set for much misadventure in software development, but it can be done if you are willing to learn and surround yourself with the right people.
Working as a developer and a technical lead myself for some years now. I have seen none developers try to manage developers with varying levels of success.
Based on this, here are some of my top tips on managing devs if you are not one yourself.
A lot of the woes of development teams stem from a lack of transparency on what they are doing and how long and how long it might take. If they do not currently have a way of working transparently so that even the none technical can understand, you need to help them develop one right away. If you can’t do this, you can not assess their capacity; you can not assess if you have too much or too little development resource, and you will not be able to generate even slightly reliable times estimates for work.
Dev teams break down when overloaded. You can not force two pounds of manure into a one-pound bag. You can’t immediately see the resultant mess when you do it to a dev team, but its there, and you will smell it before too long in the form of technical debt and an unhappy workforce.
Somebody must carefully control all workflow to the devs and ensure the machine does not become overloaded. No exceptions.
Developers can find it pretty exhausting when a non-technical person manages them. Rightly or wrongly, It instantly puts you in a respect deficit situation. You have to be likeable, so developers want to please you.
Behave like a d**k, and you will not get the co-operation you need to do your job well.
We all know the dev room can smell like the elephant house. But best not to walk in and declare it.
Developers are seriously in demand. There are not enough of them to go around, and at the moment, any half-decent developer could find another job in days.
Don’t expect them to give up their weekends and evenings for free. If they wanted to work during that time, they could be moonlighting at contractors' rates. Don’t assume you can give them free pizza, and they will be grateful that they stayed till 10.
If a dev is unhappy, they won’t hang around.
You can’t mentor developers in technical matters if you are not from a development background, so if there’s nobody qualified enough in the team to act as a mentor, you need to bring someone in. This is particularly important in remote teams.
Communication is not often the forte of developers.
If they are raising a concern about an aspect of development, even if they can’t explain themself fully and coherently, you need to coach them so you can understand their problems. Do not just dismiss them because issues they are highlighting or the long-term consequence are not immediately apparent to you. So many times, I have seen businesses make decisions with adverse effects, which developers attempted to highlight as an issue before it occurred.
Not Being able to assess your team's work is a big issue for none technical managers. You can evaluate the finished product, but not what makes it. And you are trusting the developers to build something when they know full well you can not govern them. This requires more trust than perhaps should be given.
Employ somebody senior who can review code and ask awkward questions.
If you were, you’d be the developer.