I find it astounding how many development shops (from talking to many people over the years including my own experiences) frustrate the hell out of its own very motivated developers and push very good developers away literally. Pushing them away because a manager or set of managers are too stubborn and fail often to truly listen to the very people who they have hired to "do a great job" and to "give advice on what can be improved in order to benefit the business". Or maybe a manager has talked the talked but not walked the walk with their developers giving them a false sense that change can happen or suggestions will be truly considered. Even when that means a radical departure from the current practices or coding standards. One article that addresses this very notion that "we" own the business, can be found posted by Derik Whittaker called "Should not be 'The Business', but should be 'Our Business'.
As a development manager, your developers are your best assets hands down. Development managers should obviously care about the morale if his/her team but many just do not as evident by their repeated actions. Morale does not consist just of how nice your manager is and how he can pep talk you, or motivate you. It is much, much deeper than this naive view of management and overall sense of work satisfaction and overall happiness at the workplace often imposed by some. And many naive managers try to "Sell" things that their developers have come up with good research as to why that sale will fail and yet the manager keeps pounding that sale while completely ignoring the developers who try to give great alternatives (proof of concepts, actual research) to better achieve those goals.
Managers should be very lucky if they have some developers in their team that have experienced great things in past positions that they can use to improve the current team/process, and who truly care about code standards and best practices that will help enable the business to succeed. Making the business succeed often does NOT happen because managers do not listen to their developers and take cues on what should or can change in the process, culture, or whatever it may be. They then lose those "good" developers and often end up settling with those more lazy developers who just care about "getting that paycheck" and going home.
So, with that said, a manager should be concerned about having a "happy & satisfied team" which means a more productive output for the business.
I think one way to do this is gauge our team's happiness by holding frequent open & honest feedback sessions with their developers.
Now let me first put to rest a few assumptions that may come up here:
1) I know not every developer has experienced frustration in your current or past development environment or past environments. If that is the case, I really think that's great.
2) I am not advocating that a manger "must" fulfill every feedback item they receive from his/her development team
3) Call them constructive "rants", "venting", "process or code improvement suggestion", etc. but it is what it is and it's feedback as harsh as it may be. At the same time the developer giving the feedback should be able to be blunt if he wants to be, but not in a rude manor or aimed at any one person or people.
4) Making your employees truly happy is definitely not an exact science but there are obvious things you can do to increase it and this is just one idea
5) Sure it would be nice to always take a positive note on everything all the time, and know what things you are doing good as a team. But that's not going to always help you to improve what's not working well or making your workers happy and productive.
The manager would do only the following in these short feedback sessions:
1) Listen to every sentence your developer is telling you
- If they want to give a lot of detail, let them and don't listen to only half of it if that developer is giving you a book. You want to soak in as much as you can in these sessions from your team. This is their time to tell YOU what's wrong, what could be changed, or whatever else they have to say that normally they would have just kept inside for fear, for lack of motivation, or whatever the case may have been
2) Do not take the feedback personal or intimidate them in any way from providing that feedback
- It's their time to provide you feedback. Whether you may not agree with comments, stay neutral and take note
- Don't make a developer feel (through tone or actions) like he's out of place, incompetent, or ridiculous for any feedback he/she is providing you
3) Probe to get more details in a neutral manor
Example:
One of your developers states: "We truly are not practicing ORM. We first need to have a Data Layer that can support creation of a true Business Layer and the current one is not extendable and horribly inefficient or unable to adapt painlessly with future business features"
Your response as the manager: "What are the walls causing the inefficiency and reasons why nobody has been able to build that Business Layer easily? How can the business layer really help us, because I thought that having that layer would be overly complex and confusing"
4) Literally jotting down these points on the whiteboard as you go, so your developers can see that you care by creating a formal "parking lot" list.
A feedback session to me should be one that brings out the weaknesses of process or culture by that development team in their very own words unpolished as it may come out. What better feedback could you expect as a manager straight from the horses mouth. And it's not a typical "development meeting" to hash out design decisions, but just pure honest feedback and wishes by its developers.
Your goal should be to squeeze out of your developers what makes them unhappy currently in their job in term of process, culture, etc. It's to periodically allow them to constructively rant or bring up suggestions for improvements but let them be "real" in doing so.
By doing this, you are letting them know up front that hey, I an not sitting here in some black hole in my office. I really care. And this should NOT be viewed as a weakness but a trait of a great manager if he so desires to hold these type of sessions. A confident manager would not view this as something that would make him/her weak.
Development managers should evolve with the business, but don't forget to do this by evolving with your team, it's development process, and its overall satisfaction in doing so.
Let me know your thoughts. Is this down to earth, makes some good sense, radical, risky, unrealistic, crazy, or what?
