Technically, like you, I guess I'm management, since I spend much more time communicating and leading teams than I do writing code.... but here's my take from both ends of the management horizon. Whether I'm a developer or a manager working for another manager, here's some stuff that helps in my communication with my management:
- Why? is a very important question - almost any factual answer has a "why" behind it and that "why" may well be more important than the actual question. There's a few tangents to this:
- The Developer Why - Developers will have a lot of answers that make absolutely no sense to management. I certainly did, and one of the ways I got into management was being really good at explaining the teams "whys" in terms management could understand. If you don't have a "speaker for the geeks" on hand, you can learn to speak geek by restating their answers to the why question in more commonly understood metaphors. Keep at it until you both understand and agree on what's going on.
- The Management Why - your "why" is just as important. Why do you need the time estimates? What are you using them for? How screwed will we be as a company if they are too high or too low? This is stuff that you as a manager probably have keen insights into, but this is all voodoo to the developer. The trick is, the developer may not ask. Management has asked him for something, and he's going to do the best he can to be accurate, timely and thoughtful - but if he doesn't know the "why" he may optimize in ways you would rather he didn't. Offer your why, and ask for him to do the same thing - restate the answer in his own terms. Similarly - go into the why of the business - often developers care but have no direct knowledge of how the business development works - having someone volunteer this information is both motivating and enlightening.
About time estimates specifically - I've had to do a ton, and I have absolutely profited from telling my development team "I need this because I am going to ask for more money to pay our salaries, I will trust what you tell me and I will use your numbers... that means that if you low ball on me, we are all screwed because I will not be able to ask for money a second time - we have to live with what we propose". With that context, developers changed from low estimates that attempted to show me how confident and brilliant they were to high estimates that came a lot closer to real expectation setting.
- No one is wrong - The "why" question goes a long with a corollary - asking "why" instead of saying "that's outrageous! No way!" keeps the conversation flowing. Sometimes there is a severe disconnect between what someone things is being asked and what the asker is asking. My best management has been horribly surprised by my answers, and when surprised, they blink in astonishment and then ask "why do you say that?". They do not say (immediately) - "you need to change it". I have reduced numbers on proposals to meet a competitive goal, but only after talking intensely about how we could change the scene and create a different context for the question.
listen for ambient noise, word choice and the space between the words - Here's a bunch of things I have liked and stolen to use myself:
- hang out in the work area, do something productive of your own (don't try to get in developer work, they know you're not a developer) and just listen. How does the team solve problems? What are their big problems? You will never hear the real skinny on their direct assessment of you or management at large, but you may get a really good sense of where problem areas are. Make sure you're doing something of your own that is productive. No one likes spying, but unless morale is so low that you can't be near them with out everyone evacuating, productivity within proximity should be tolerable.
- look for word choices - they are often as important as the words themselves. When I've used particularly positive or negative words, my management frequently asks me why I chose those words when it's a situation they aren't familiar with.
- look for pauses, gaps and body language. If there's a power distance between yourself and the developers (and it sounds like there is) they may not want to contradict or confront you. But the basic instinct to say "hey, you're wrong" usually manifests itself somewhere.
- open up to as many communication mediums as possible - be ready to chat in person, on the phone, by email, by IM - anything and everything to establish the flow of communication. People are so diverse that just one trick won't work. And I see it as the manager's job to be the multi-format communicator, not the developer's.
- make it worthwhile talking to you If someone tells you about a problem and maybe a possible solution, he should and probably accept that you are the manager and therefor may decide in favor of a different solution, or no solution at all because you don't think it worth the trouble. But after the third time this happens, especially if it happens without an explanation about 99% of the people will stop telling you anything.
And here's one that's incredibly hard for me, but has worked great when I can do it - be aware of the difference between introverts and extroverts. Chances are that you are an extrovert - that's why your job seemed good and a development position did not. Developers are, for the most part, introverts. "Introvert" does not mean "can't communicate", but it means that their pattern, process and velocity are significantly different and the urge to communicate incessantly is virtually non-existent. Plan in the time and quiet (but collocated) space to let introvert based thoughts to come out. Many of my introvert friends tell me they are just waiting for me to "shut up for like 5 minutes" so they can put together a thought and respond. Here's a few great articles on the same thing - 5 things extroverts should know about introverts and Rands in Repose on the Nerd Cave - a particularly developer-tastic example of what's great for introverts. Rands is pretty fantastic, by the way. He's a geek himself, so he comes at it from a developer-focus, which can be off putting if that's not your style, but he's funny and has some really good insights on team development.
I think the #1 things I have loved about my favorite managers was:
- they were as deeply committed and excited about the project as I was (if not more)
- I never had a doubt that they had my back - I knew with certainty that when they were in front of the next level of authority that I (or my peers) would never be the scape goat. It would always be a group failure, if there was failure.
- I was given ownership of something significant and appropriate for my skills at the time, but with enough resources to expand my skills and get the job done.
- they saw me as both an individual and as part of the team - they were actively engaged in knowing my strengths and weaknesses and working to help me play on my strengths and augment my weaknesses.
- they were aware of my personal goals and interested incorporating them as much as they could
- they were upfront when making me happy couldn't and wouldn't be a priority. There's a real value in hearing "I know you hate this type of work, but I need you to do it - here's how it won't be forever...".
- there was always time in a week (maybe not at the instant) to explain the big picture
- there was near constant feedback and status with no finger pointing but plenty of recognition for individual work.
- there was always the truth. If something was sensitive and couldn't be discussed, they said so point blank. If something was uncertain, they gave a level of confidence.