I'm a manager. How can I improve work relationships and communication with programmers? [closed]

Question

A little background first. I'm a project manager at medium-sized company. I started as a CS major and had a little exposure to programming, but after a few months I knew it's not my path, so I switched over to management. That proved to be a good decision, and after graduating I've worked in software management at various companies (for 5 years now).

Recently, we had a very painful project. It was the worst of the worst, with many mistakes both on our side and on the customers side and just barely ending it without losses. It has led to many frustrating situations, one of which escalated to the point where one of our senior developers left company after a vocal argument with us (the management). This was a red flag for me: I did something terribly wrong. (for the record, the argument was about several mistaken time estimates)

I searched many places for answers and a friend pointed me to this site. There are many questions here about frustrations with management. I can understand that the general bad experiences lead to a general reluctance against "those guys in the suits".

I'm that guy in the suit. It may not look like it, but all I want is a successful project, and with limited resources it takes painful decisions. That's my job. One of the things the aforementioned senior developer complained about was work equipment. Frankly, I had no idea that the computers we had were not suited for working. After this, I asked many programmers and the general consensus was that we need better machines. I fixed that since then, but there was obviously a huge communication gap between me and the programmers. Some of the most brilliant developers are the most shy and silent people. I know that, and it was never a problem during an interview. People are different, and have strengths at different areas.

The case of the underpowered PCs is just one of the many that led me to thinking that there is a communication issue. How can I improve communication with programmers without being intimidating and repetitive?

What I'm hoping is that people don't complain about good things. If you love your workplace and love (or at least like :)) your manager, please tell me about them. What are they doing right? Similarly, if you hate it, please describe in detail why. I'm looking for answers about improving communication because I think that is my problem, but I might be wrong.

Answer 1

Wow! Thanks for asking. 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.

Answer 2

The easy part first: there's a technical red flag in your post: I shudder at your mention of "mistaken estimates" - it's an estimate, it CANNOT BE MISTAKEN, that's why it's called an estimate. It can be off a little, it can be off a lot, that's why it's called an estimate. If you are taking estimates as gospel, that's going to be one of the main problems that "your" developers are having with your style.

However, I 100% agree with you about the difficulty of communicating with developers. I had a revelation several years back, as a developer in a project management training. I saw several of my fellow developers absolutely railing against management after an open atmosphere of discussion was created (management was present here). Everything that was wrong was the fault of the managers in the eyes of the developers. The kicker was that management had no idea about nearly all of the huge issues that were raised that day. Developers were assuming that it was all so obvious that management couldn't possibly have missed it, and management was assuming that developers would tell them what they need.

Therefore, IMHO the first part of the answer must be to let your developers know that you are not psychic, and in fact probably downright stupid when it comes to the technical side. You are relying on, counting on and trusting them to come to you in a timely fashion. You are there to make their life easier, not harder.

And whatever you do, do NOT ask them questions you don't actually want to know the answer to - referring to the "mistaken estimates" above ;-). That's a developer's kryptonite.

Answer 3

There's a lot of good stuff here but I feel the following need to be said.. ..Sorry to be harsh.. But this need to be said:

• 5 Years as a PM, and to not know what kind of PC a developer needs, is outrageous.
• To have a developer quit because of bad working conditions as your first real red flag, is insane.

What I think you have is a Trust issue, more so than a communication issue. No one tells what is wrong because they don't trust what you will do with that info, and may even fear it will be used against them. The dev that told you about all these issues did so because there was no consequences in doing so, he was quitting.

Personally I would never hire a PM who did not have some development experience in his background. I think on your next project, you should dedicate a small portion of your time as part of the Dev. team. Say 8 hours a week, working as Jr developer under the team lead.

This will really open your eyes to the dynamics of a development team, because right now, you are not even part of that team, you are an outsider. The fact that your dev quitting came a shock to you, proves it. Everyone on the team knew he was unhappy. And not one of them told you :

"We are going to lose our best guy if you don't do something"

That should be red flag #2.

Answer 4

As a manager I'm sure you heard about kaizen, one of the tenets of the Toyota Production System meaning continuous improvement.

You admitted you have a problem, so, that's a great start.

Kaizen has five primary elements:

• Quality Circles: Groups which meet to discuss quality levels concerning all aspects of a company's running.

• Improved Morale: Strong morale amongst the workforce is a crucial step to achieving long-term efficiency and productivity, and kaizen sets it as a foundational task to keep constant contact with employee morale.

• Teamwork: A strong company is a company that pulls together every step of the way. Kaizen aims to help employees and management look at themselves as members of a team, rather than competitors.

• Personal Discipline: A team cannot succeed without each member of the team being strong in themselves. A commitment to personal discipline by each employee ensures that the team will remain strong.

• Suggestions for Improvement: By requesting feedback from each member of the team, the management ensures that all problems are looked at and addressed before they become significant.

(Source)

If you take a long look at this a constant over those elements is the emphasize on teamwork and feedback.

An example, you say you had an argument over time estimates. Are you the responsible for those time estimates? Do you talk with the team about that? I'm sorry but I've seen managers just pull out a number from their as-. One crucial thing: never haggle over time estimates your team gives to you. A lot of managers imagine that if they can meet shorter time deadlines if their team works harder. This is a lie. Nine women can't have a baby in one month, remember that.

So, my first advice:

Listen: start with a simple e-mail to the team: "What's the best way for the development team to give feedback to the management about the management performance?". Iterate with the team and implement the consensus. Your task is to allow the team to develop great software, not to herd them. Keep this in mind.

Honesty and Loyalty: If no ones answers when you ask something, it's because they don't believe you will listen or, worst yet, they believe you will punish them for that. So be honest. If someones says you suck, take this as a feedback and do not take revenge. Understand their reasons, improve on it.

And, at last, although I've seen some critiques about it here, I'd like to recommend you to read a book called The Mythical Man-Month: Essays on Software Engineering. The book is about Fred Brooks experience at IBM while managing the development of OS/360. While a few things here and there may be dated, it's the starting step to understand how the development process of complex software works. S.Lott cites the Agile Manifesto, which I'm not particularly keen on it, but it's also worth reading.

Answer 5

Read this:

http://agilemanifesto.org/

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

In many cases, the organization (i.e., your boss) demands that you

• follow a clearly broken process to it's logical conclusion leading to a "death march". This leads in turn to arguments and resignations.

• create excessive, low value, unused documentation.

• engage in complex change control a/k/a contract negotiation. Every user change requires an elaborate ritual to "quality" and "prioritize" the change. Really, it's all about the "freeze" -- preventing change.

• follow the plan irrespective of the consequences. Some organizations value on-time delivery of broken (or even useless) software. It's the plan that's valued, not the solution of a business problem.

It may be that the issue isn't your personal communication skills.

It may be that the entire development "environment" or "methodology" is fatally broken, and bad feelings are just a symptom of general bad practices.

Answer 6

To me this sounds like you never talked with the devs in an easy atmosphere. Your talks with them were merely of official nature? That's too bad.

Why don't you get to know them personally and thus get to know what's good and what's bad about the company, their workplace and their projects? Respect them and earn their respect, by showing sincere interest and appreciation for their work.

If they trust you and needn't fear about being pawn offers, they will most likely even tell you unattractive truths.

I am a Team-Lead and my team trusts me. I protect them. I take all the blame and I share the fame with them. Our management protects me. That boosts the morale. We had a really hard project and an almost evil customer, nearly impossible to finish but we did it eventually, because we talk about everything in a very frank and open manner.

Answer 7

Clap! Clap! Clap! You certainly should be a good person, for you have come out in open to see what can be done to get better at your job.

Please find below what I have witnessed in a great manager, and have personally adopted when I lead the team as a senior member.

• M entor more than manage.
• A llow team members to voice their thoughts and concerns. Be all ears to it. Take the constructive ones.
• N ever betray team members by playing divisive politics. This back-fires sooner and silently.
• A nger not. Never have grimaces on your face when you are with your team, come what may. This one is really difficult.
• G enuinely and openly appreciate the winner for his/her good work. In the same breadth, very softly and tactically cricicize the work not person for any wrongs, to the person who is responsible, in isolation and not in open.
• E ncourage ownership and leadership in every individual. This boosts the morale and commitment of the person, because he would feel respected.
• R oam around with your team once in a while. This one induces/increases bonding within team members.

Wish you good luck in your sincere endeavour :)

Answer 8

In general, the guys in the trenches start feeling mutinous when they feel their gripes aren't being heard by people who can and will fix the situations. When they don't even feel they can gripe without risking their standing in the company, that's even worse.

I'm a Theory-Y kinda guy, and most "knowledge workers" tend to be; Given a chance, we like our work, and want to do it well. However, the downside of a Theory-Y workplace is that it may not be immediately apparent there's a problem, because people, wanting to do well and thus not wanting to make waves, will find ways around that problem, or simply ignore it. This leads to pent-up frustration, that eventually blows up in the entire team's face. A shop run by a Theory-X manager would probably have guys that complain much earlier; the employees are only in it for the money, so if the job sucks more than usual they'll gripe.

As for what you can do, in an environment with seniors and leads in the room doing the job, they are your best asset. Talk to them. You might schedule 30 minutes a week for "two-ways", where the leads give you updates and air concerns about the day-to-day of the project, and you give them updates on the business side and plan with them to resolve concerns before they become problems that seriously affect the team.

In Agile, at the end of each "sprint" or "iteration" (which is a unit of development work usually lasting between one and three weeks), the entire team, from the most junior members up to the PM, has a "retrospective". They look back at what they did, what went right, what didn't, and identify things to keep doing and things to change. There are several formats, and you can invent your own, but the result of the retro should be that people feel their voice was heard, and that things will change as a result.

Talking about Agile; my first job was for a small company, and by "small" I mean the whole firm couldn't field a softball team. There were four programmers when I started, and that dwindled to two before I left. The founder, President, CEO and 95% stakeholder in the company ruled it with an iron fist, and he was the sole source of planning in the organization, meaning there wasn't much. The Boss was a workaholic and expected everyone else to be as well; Everything you had to give was no more or less than his expectation, and for this he paid an entry-level salary to people who'd worked for him for a decade.

I left that company and began work for another firm that did things VERY differently; they practiced the SCRUM Agile basic methodology, with daily standups, pair programming, sprint teams and retrospectives. For one day every two weeks at the beginning of each sprint, we did nothing but plan out the next two weeks' work. For a big chunk of another day, we did nothing but look back on what we'd done and find ways to improve as a team. There were developers sitting next to me who were Microsoft MVPs, getting the job done, and encouraging and complementing what I was doing.

Night. And. Day. The main difference? First, I did not feel like I was expected to kill myself for the project; a fundamental tenet of Agile is the sustainable pace of development. Second, I had a voice in deciding how I would be expected to do my work. I had to do the work, but if I had "heartburn" over what I was going to be expected to pull off in the next sprint, I could voice that opinion and it would be heard and given weight. If I felt there was a better way, I could say so and it would be entertained.

As far as finding solutions and resolving problems, you must be careful not to look like you're working from the top down. For computers; say your RMR (recurring monthly revenue) only allows the company to upgrade four computers ever two weeks. The first four computers should not all go to the leads and seniors; they should go to the people with the slowest computers. If you give bonuses to the team, don't just give them to "our valuable seniors and leads, without whom this wouldn't have been possible"; EVERYONE in your dev team made it happen. If a junior has a complaint, hear him out; just because he's a junior doesn't mean he doesn't know anything.

Answer 9

Improving relations:
Just had a hard project? Give them a break afterwards. Vacation time to go unwind, get their breath.
Coders bill of rights These things are a given. Basic things that should go without saying. If you violate these, you are abusing your codemonkeys.
The Joel test I agree with most of them. But some really depend. If you're missing some, you're probably making life for your programmers harder then it needs to be.
Technical debt. So you can push for completion, but you have to realize that by cutting corners you incur technical debt that will take more time at a latter date to fix. If that date comes up BEFORE the end of the project, you've really screwed up.
RSA animate: Motivation This is a fantastic bit that really shows how to motivate knowledge workers.
Free day to code what they want. From the RSA video. Don't remember the name, but the company it mentions has a short explanation of it on their site. Seems like a good idea to me. In most shops there are things that everyone knows is busted, but nobody has time to fix, and it's not a high priority. This lets them tackle technical debt. It also lets them show off their brilliant ideas.

And for the love of god, try to keep a 40 hour work week. Also, flextime. Flextime can make up for a whole world of bullshit. For me at least.

Improving communication between programmers and bosses
That's tougher for me. That whole shmoozing thing is more of a boss skillset then a programmer's focus. I could say some basic things like time estimates are only estimates. Walking on water and fulfilling requirements are easy if they're frozen. Maybe asking the shy programmers to give a presentation on their project at a code review or something. Practice makes perfect, ya? But I'd bow to others' advice on this one.

"Similarly, if you hate it, please describe in detail why."
Well that's going to open up the floodgates here. And if I wasn't using an openID that could obviously be linked to me, I'd probably vent too. If you really want a giant list of what not to do, ask on a forum that's more friendly to anonymous posting.

Answer 10

I've always found that people in general will not treat you any better than you treat them (though they may treat you worse). I personally (I'm a developer) respond to honesty with honesty, to respect with respect, to trust with trust, and so on. You should have an informal chat with your team in a neutral atmosphere, and tell them what you just told us. The point that gets forgotten in the toxic "us versus them" environments is that it should all be "us". Both management and workers need to know that, and the enterprise must support that.

Good luck.

Answer 11

You now have a proven record of not only accepting feedback, but acting on it. You've demonstrated that you have influence with higher decision makers and you can get things done for your team. That makes a big difference. Programmers my be more introverted, but we like to talk about programming. An informal environment is nice, but everyone still needs to be professional. Allow people to vent some, but make sure the discussions are productive and not just a bitch session.

Answer 12

From my experience, the most significant factor for me to like or dislike my manager is if he/she understands development in general and understands the work I am doing. Some positive results are listed here:

• I don't have to waste too much time to justify why would a change take so long or cannot be implemented. Well, technically, any change can be implemented and upper management usually demands the implementation any way. But at least in such a situation, your direct manager is on your side, asking for more time (instead of pushing you or burning you out).
• I know I have a better chance to be supported in case of a bad situation (a WTF hack, a production issue, etc.). Usually, non-technical person tend to blame developer for such a situation while a good manager UNDERSTANDS what's really going on and supports his/her developer (not just know or willing to take it that way for being nice).
• I know my work and performance are to be evaluated by a proper person.

In my opinion, if you don't do programming any more and usually in a tight project schedule or budget, the chance for your developers to like is very low. If that's the case, you better move up quickly and have some one else to be the direct manager. Sorry I sounded bad in this paragraph but that's the way I see it. Your seems to be a good person and deserves some truth.

Answer 13

I am also one of the guys in a suit, and have been for more than 15 years. I was a software developer when I started out, and I still write code when I get a chance. So I think I can talk for both sides and I have a bit of experience in these situations. I also have credentials, such as "Employee of the year", elected by staff, that make me confident in handling these situations.

What I witness very often is that there are substantial differences in the value systems and operational methods/approaches taken between management and developers.

For a lot of developers, sincerity, honesty and otherwise a flexible work environment are very high on the list. Unfortunately the very same values are not very high on the list of top management. And this leads inevitably to huge clashes, particularly if middle management (you and I) decide to completely take the top management side. The only way out of this (from my point of view) is by taking a firm stand in front of your team, backing them all the way, and building a trust relationship through open communication and, most importantly, by doing what you are saying (which is often the opposite of what you get from top management, where politics completely overpower sincerity).

At the same time you yourself need to stay operational, so you have to find a way to communicate to top management in a language they understand and play their game. That is the true challenge of middle management.

Answer 14

I believe that with developer happiness productivity all comes down to the little things. The math works out pretty awesome for management. Give me a donut(-25 cents) in the morning and I will work twice as hard all day(+many dollars). It is not that we actively sabatoge things by working slow when we are dissatisfied, it is that we are working on extremely complicated systems and it is extremely difficult to focus when we are frustrated about something. It is really probably better that we do not code as much when we are angry.

Estimates, however, must be addressed by themselves. Every issue I have can be solved by handing me a donut, with the exception except unrealistic estimates. True or false this is how a developer sees it: Management has everything to gain (like a new boat) by a shorter estimate, while developers have everything to lose (like a month's worth of sleep). Management is in charge though, so they win the estimate war every time. I think the estimate system works best when developers decide the deadline (it's hard enough for us to give an accurate estimate, so how would a manager?), but management positively motivates them to be ambitious, with the understanding that no developers get railroaded for being a bit off.

Answer 15

Consider what kind of reaction do you give a programmer that may have a question, comment or concern. Is there a, "What do you want now?" or "Why are you bothering me with this?" kind of a response? How well are you at encouraging the developers to voice concerns and comments? That is merely a starting point though.

Secondly, be careful of where you are trying to have these discussions. I doubt I'd be very open discussing my work machine with someone in the next cube if I knew my manager was within earshot of hearing the whole thing. If you want people to give open and honest feedback, there has to be some privacy given to knowing their answers aren't going to be publicly broadcast or used against them.

Third, consider what kind of Emotional Intelligence skills do you have. Emotional Intelligence for Project Managers: The People Skills You Need to Achieve Outstanding Results by Anthony Mersino would be a book recommendation I got yesterday from a Lunch and Learn about EQ. If you really want to get deep into psychology here there are various personality profile tools that could be used,e.g. Enneagram, social styles, and MBTI.

Lastly, consider what is the culture in your company. Are mistakes something swept under the rug? Are complaints a big no-no that could get someone in trouble really easily? What behaviors are rewarded or encouraged and which are tolerated and accepted? While some of this is observation, some of it may also require some conversations that should be held either away from the office or in a room where there isn't likely to be eavesdropping. You will likely be repetitive in trying to use this in the beginning. That isn't a bad thing if you are trying to establish a new practice and get people on board with speaking up if the culture was primarily one where everyone just knew to "suck it up." This may be more touchy-feely than other answers but this would be what I'd give for an answer if I was asked about this where I work.

Answer 16

Do the devs feel that you are their advocate? By that I mean that they know they are free to share with you their concerns/frustrations without being beaten up? Do they feel that you fight for them? Do they feel that you appreciate their work? Do they feel that you genuinely want them to succeed in their career?

If they feel appreciated, you'll probably have better communication.

Answer 17

As a developer I'm a major nerd and lack social skills and I make no apologies about it. After all, I'm the talent, and you've hired me for my talent. If you needed social butterfly's to do the job you'd have a room full of project managers instead of developers.

I know that some developers are very socially astute, but I think the median leans toward introverted nerd.

When someone requests me to do something I make absolutely no inferences and do EXACTLY what is requested. It seems like with some project managers I always end up with problems because they expect me to make inferences about their project which I absolutely will not do, so sometimes things don't turn out as they expect even though they turn out to be exactly what they have requested. I think the reason that this happens with some project managers is because they don't deliver high quality HLDs, BRDs and place too much value in the social aspect of project management rather than what's in black and white.

I think that this is where worlds collide. I think in the world of project management the social skills and quality of personal candor are important factors, but to developers like me it means absolutely nothing. It doesn't impress me to yammer on about how important this or that task is. I don't even want to go out for lunch or beers like some people here have suggested.

What I really want are good, high quality HLDs and BRDs. I want schedules and deadlines that are achievable, and if new designs or plans are introduced, I want the schedule and deadlines to be re-adjusted. I've worked on projects where the requirements seem to change on the fly -- to me this is my red flag that I'm dealing with poor quality project leadership. As a developer the worst thing you can do is bring me new project requirements on a daily basis, especially after we already have a schedule or have made schedule commitments. It's intolerable when new requirements are brought in, without compensation to deadlines. Working more hours, working late, I have no problem with that, but it's not something that's always quantitative with development. Some changes can take a few extra hours, some changes could take weeks for proper R&D, testing, QA etc... It's not always like baking a cake, sometimes a single change to the requirements can be like changing the whole recipe. I've witnessed project managers melt down and have temper tantrums on conference calls because their deadlines wont permit the extra development, yet they're asking for development which was not in their initial project requirements.

I can only give my own personal bias and experience as an example so please don't infer that I'm speaking in behalf of all developers. I only see these things through the microcosm of my own career but this post describes exact conditions that caused me to throw in the proverbial towel.

Answer 18

How often are you talking to your developers? I don't mean project status meetings, questions about deliverables or other topics that you bring to them - how often do you sit down with one of your programmers, ask them how things are going, and just listen.

A lot of the other answers are really good - you should look into agile development. You need your developers to learn and grown in their roles. But if you're not actually listening to what your developers are (or are not!) saying, then you need to take care of that first.

Good reference on one-on-ones - http://www.randsinrepose.com/archives/2010/09/22/the_update_the_vent_and_the_disaster.html

Answer 19

Short and sweet. Excel at what you do - this will engender communication.

What does excelling mean to your developers ? .. Read, re-read, yes even study PeopleWare

Answer 20

All great ideas and comments in the posts above!

Here's an idea: send your I.T. staff to communication workshops at your local community college - paid by the company, of course.

Make sure a) the workshops have a good reputation, and b) not to send your employees together. They will tend to stick together and not mingle with the other class members, not only reducing the value of the workshops, but causing disruption to the others.

Productive team oriented communication is a skill that anyone can learn, but is a subject matter I feel is lacking in most scholastic paths.

This idea is in no way a magic bullet, but it is a good foundation piece of the puzzle. Not only will your associates learn to communicate better with each other, but the bonus will be, that they will start to understand and respect YOUR work better, too (communication being at the core of PM).

Just my 2 bits :)

Answer 21

Just to make an answer out of a recommendation that has been coming up in a few answers already. Michael Lopp (a.k.a. rands) has been writing about managing developers and "getting in their heads" on his blog, Rands in Repose, and in a book, Managing Humans (book sources). The book contains mostly edited content from his posts prior to 2007, and provides a good way to catch up with the management-related parts of his blog (he also talks about e.g. gambling, and whether you want to read that is another matter). His writing is generally great & often humorous, so there is little risk in reading him.

Answer 22

Take the team out for beer (and you're buying).

Answer 23

I'm late to the party, but just saw this question.

One thing I don't see very well addressed is this:

Grunts don't ever tell the whole truth to the suits. Rands says this in DNA but doesn't address it head-on, he's on a different topic.

You are wearing a suit, and you sign the checks. You represent the interest of the company. You are not representing the engineers. If you did, you'd not be signing their checks, they'd be signing yours.

This is of course not news to you or the engineers. But when an engineer knows that bring up certain issues - problems - with his workplace would cause significant conflict - the risk/reward tradeoff does not favor the engineer. Engineers are paid to produce product, not kick off workplace culture fights. Getting involved in those is a fast track to doing the job wrong.

So part of the management task is to provide a way for the engineers to be open about problems, without incurring corporate politics & career backlash. It's nice to have raises, after all, and there are other companies, if this one doesn't feel congenial.

Answer 24

I'm surprised noone has mentioned this great book which is dealing exactly with your question and subject - "Peopleware: Productive Projects and Teams" by DeMarco and Lister. From the editorial : the major issues of software development are human, not technical . The first three reviews on amazon would easily be enough to convince me to buy this book if I was in your situation.

Answer 25

A lot of the answers here have very good points, but I would just like to throw in a couple of resources that might help. I've been in a few situations that either crumbled in on themselves into a giant mess or were solved very efficiently because of communication between the people involved. Three books have helped my personally improve my communication skills, especially in high-stress situations where there is a lot on the line:

• Difficult Conversations: How to Discuss What Matters Most
• Crucial Conversations: Tools for Talking When Stakes Are High
• Crucial Confrontations: Tools for Resolving broken promises, violated expectations, and bad behavior

From reading your question, I think you see the value of communication. I personally feel that communication is more important to a manager or leader than business or technical skills. The people that you are leading should have the hard skills that you need to get the majority of the project done. A good technical leader or project manager should be able to focus on communication, whether it is within the team or between the team and the customer or the team and the business entity (or even a combination of those three).

Answer 26

Read a couple great novels which give insight into the perspectives of the technical workforce:

• Hackers, Steven Levy - http://en.wikipedia.org/wiki/Steven_Levy
• Microserfs, Douglas Coupland - http://en.wikipedia.org/wiki/Douglas_Coupland
• Cathedral and the Bazaar, Eric Raymond - http://en.wikipedia.org/wiki/Cathedral_and_the_Bazaar

These are as important as any typical memoir on management (Drucker et al).

Answer 27

I have done various roles over many many years - developer, senior developer, technical lead etc.

From your question - it's quite obvious that your developers don't tell you stuff because they don't think you can help.

This may be because of 2 reasons.

1. They don't think you have the power to fix things. However, I think this is unlikely because then you probably would know it & also the developers would have whined about it to you.
2. You are the kind of person who when a developer comes to you with a problem, does one or more of the following things
   • When they come to you with problems, you tell them - I like solutions not problems.
   • You listen to them nicely & then task them with fixing the problem. You give them pep talk about what an honour it is for them be given the responsibility to fix the problem. Over time your guys understand that when they go to you with a problem, they will end up with extra work, so they don't come to you with problems.
   • You deny it's a problem. You give convincing reasons for this. But as this keeps happening, over time your guys learn that there is no point approaching you with a problem.
   • You say "Yes, I understand". You say this kind of stuff happens occasionally & there is nothing one can do. If this is a pattern, then again your guys understand it.

If it's any or all of the above, then you need to rectify it.

Answer 28

The thing I hate most is people getting in-between me, the developer, and the end user. The best managers let me do this and change our solution to match what I think the user wants or could do with.

The worst practice to me is often dress up as "good" - usually the manager has themselves, or a BA or someone write specs which the develoeprs have to interpret and implement, with timescales agreed beforehand.

If its a customised solution often even the developers wont know how long it will take and usually the customer hasn't a clue what is best for them. That is why itereative development is great. Isn't the way most deals are done though so a good manager will fight to work as above.

Finally some developers aren't good at communication and can't relate to customers. They are perhaps best suited to problems with clear requirements, especially clear technical requirements. Perhaps you need developers which are better communicators and want to work to solve busieness problems not pure technical ones.

Answer 29

It is very easy to keep the team happy

Try to listen to them many time their question has answers also in it. i would encourage team member to come with problems and the probable solution.

Team outing is a good idea (might be some game plan)

if your project require some late nights and weekend work and you think that you actually dont add a lot of value to the team still it would be a good idea to come some time with something to eat and appreciate the team about their efforts and if possible arrange some PTO forthem

do a bimonthly 1:1 with every team member to make sure that they are comfortable.

Last but not least it might be a good idea for you to understand the project functionally and somewhat technically as well.

Please let me know if you have more question

Answer 30

I'm also (french so forgive my english) software manager who have a scientific engineering background but not specifically IT software background originally. So I have no special affinity with coding at the begining but I've been a statistical quality engineer from the school of Deming which has a huge different teaching to every "modern" schools that followed though they pretend to inherit from Deming. The worst is 6 sigma, lean was better but unfortunately what happened is this http://leanandkanban.wordpress.com/2011/05/13/what-did-deming-really-say:

“Originally Six Sigma was derived from Toyota Quality Management (TQM) by Motorola to achieve six sigma levels of quality, and then through Allied Signal and GE it morphed to projects by Black Belts based on statistics to become a cost-reduction program—every project needs a clear ROI. In other words, we denigrated the program from a leadership philosophy to a bunch of one-off projects to cut costs. It was a complete bastardization of the original, and it rarely led to lasting, sustainable change because the leadership and culture were missing.

“A similar thing happened to lean when it got reduced to a toolkit (e.g., value-stream mapping, KPI boards, cells, kanban).

“Lean and Six Sigma in no way reflect the original thinking of excellent Japanese companies or their teachers like Deming.”

Today the Agile movement is like lean (see Jeff Sutherland course and his honoring of Deming http://blogs.forbes.com/stevedenning/2011/05/27/jeff-sutherland-the-21st-century-will-be-the-century-of-scrum/), it's better than Waterfall but it's still very far from the original teaching of Deming because instead of reading Deming in his original text, gurus just re-packages him approximately never quoting his whole 14 principles of Management, and sells tools and seminars that have little value by themselves.

Now when it comes to software field, problems are there are people on one hand who know the general principles but have no real ideas how to really apply them and on the other hand people who are writing softwares but ignore the principles because they just listen to fake gurus who sold them tools without telling them the real principles and they should in fact build their own management tools.

So for me the software project manager should make effort to go deeper into day to day operationality of software coding, not just doing planning in Microsoft Project (or burdown chart with Agile) or nice presentation in Powerpoint to upper management but have some values also for the developer team. When the developer team have problems even if it is technical problems, the project manager can help to orient the diagnostic with an external eyes. He can look at code, even if he doesn't understand the tiny detail, he can ask some naive questions which may trigger developers to realize they didn't think about that clue (I have numerous personal examples but it's too lengthy so I will rather write an article on my blog).

An other stuff is that I try to have a general awareness of the evolution in the field like new frameworks, new architecture paradigms by reading technical articles. I will participate in some integration tests, write some documentations myself (stuffs programmers hate so I do for them, they would of course feed me with the core), anything I am able to do practically for helping the team.

In general developers feel like they're doing the hard work, and it is true, often I do tell them that I'm doing the easy part by staying in abstraction, nevertheless I do try to help concretely when needed - because micro-management is not good either as it can generate interference feelings.

As conclusion: eliminate slogans with developers (that's in fact one of the 14 principles of Deming), show them you do care about the project concrete software, not about documents or your meeting with upper management only.