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

433

244

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.

AgentSmith

Posted 2011-07-14T14:13:18.677

Reputation: 201

Question was closed 2013-10-30T10:48:01.697

45Don't you ever take your development out for a team lunch or dinner? We do that at least once per month. Don't you have informal meetings with them, as a team, and individually (at least quarterly)? OTOH, a person managing a team of developers, who has never been a developer himself is in a difficult situation. Because of this, there could be a respect/trust issue. – Randy Minder – 2011-07-14T14:35:38.810

97Regarding equipment: your team probably costs about $100/hour. If they say they need something, a machine, a book, another monitor, a chair, a desk, a headset, get it. If you do not have authority for these trivial expenditures, expect continued turnover. – kevin cline – 2011-07-14T14:57:45.167

3@kevin -- don't forget external training as well. Each engineer has probably already paid $100k out of their pocket for their degree; and that degree is probably severely out of date (technologies change more-or-less annually). Make sure they're being sent to refreshers frequently (a major conference every year or two, small conference a couple times a year). A few thousand dollars in keeping an existing developer up-to-date is significantly cheaper than on-boarding a new hire. – STW – 2011-07-14T16:12:57.677

22My manager takes me out for lunch and pays for it, but he does not dare to ask for my input; instead he talks about how bad his last place of work was. Frankly, perhaps he better not ask because the decisions are being made abroad anyway and those are often stupid ones, IMO. My point: it is not enough to have a 1:1 or take someone out to lunch. One needs to ask straight questions but also demonstrate the ability to make reasonable changes. Without that 1:1 is useless. – Job – 2011-07-14T16:20:05.183

2

Try listening to the manager tools podcast. I personally found it very helpful.

– Aidan Cully – 2011-07-14T16:54:28.773

27This is the core of your problems IMHO...If your first red flag is a Senior Developer leaving the company after a confrontational meeting with management you need to get some new red flags. Ones that work at a finer grain of problem. Talk to the other devs solo, start with one you have the best relationship with. Ask them Why he was unhappy, but also ask When they knew he was unhappy enough to think about quitting and how they knew it. Ask how you could have noticed it, what signs they think he gave you that you missed to know it was already that big an issue. You need to see problems first. – Eric Brown - Cal – 2011-07-14T17:23:56.367

Well, never ask them to do to unnecessary documentation. My manager never does to me which is why I love him most – Tarun – 2011-07-14T18:22:12.130

2Less meeting and let your developer do more work. If you need to hold a meeting, please make it quick, short and only invite the person that really needed for the meeting. – Rudy – 2011-07-14T18:24:04.657

this link was posted on another thread that may apply somewhat. – Wayne Werner – 2011-07-14T19:12:03.247

29"How can I improve communication with programmers without being intimidating and repetitive?" Your worry about being intimidating and repetitive reveal that you think "improving communication" is something you do by talking more. Wrong. Talk less. And when you talk, ask questions. Ask if they have what they need to do their job well. Ask if deadlines are reasonable. Ask if they're feeling over- or under-challenged. Then act on their concerns - if they see that answering your questions yields actual change, they'll begin communicating proactively and you won't be blindsided again. – Michael Ames – 2011-07-14T20:32:33.723

2http://www.managinghumans.com/ – Job – 2011-07-14T21:56:02.423

2Thank you all for the great answers and the insightful comments, I didn't expect this much attention. I honestly learned a lot just by reading them. I'll go and try the suggestions and see what works for us. – AgentSmith – 2011-07-15T11:40:29.520

7One more adding to the vast list instructions of managing coders: don't disturb the coders along the day but give them to work undisturbed. The most irritating what a manager can do is to ask time to time for new features and little corrections during the day. That irritates much the flow and keeps people not concentrating well. – mico – 2011-07-15T11:56:07.047

4Many have noted you should start asking, listening, and then doing. Because you are apparently starting off with a deficit of trust and communication, don't be surprised if there is very little response initially. The first questions or needs raised may be more tests than actual real-world needs. Regardless, they'll be looking to see what you do with the information they've entrusted to you. I've always loved managers who I felt were on my side against whoever was on the other side: managers, clients, etc. That isn't something that comes overnight. And it takes hard work on the manager's part. – music2myear – 2011-07-15T18:30:58.933

2@Mikko, I'd create a category system for notification. 1) It can wait for an end of day or beginning of day email. 2) It can wait for an end of week or beginning of week email. 3) If they don't know this it may waste their day's work anyways, so tell them now. – music2myear – 2011-07-15T18:32:50.547

3Any heated discussion - especially about time estimates - is a red flag! – None – 2011-07-16T21:46:36.020

I agree with Mikko and music2myear; interruptions are not only frustrating, they are also a huge time sink. (Much more so than it might appear on the surface.) Whatever doesn't absolutely need to be said right now can and should wait. Say it in an e-mail, or right after their lunch break before they have time to get into the flow anyway. Also, I would suggest that you encourage the developers to set up a rule to file your emails automatically and deal with them at their leisure, rather than feeling pressured to respond right away because it's from their boss. – Michael Kjörling – 2011-07-18T07:52:53.910

You must be insanely lucky or have had some major connections to move to management after "a few months" as a programmer. – Wayne Molina – 2011-08-12T20:18:14.927

You must read How To Make Friends and Influence People by Dale Carnegie. It is a must read book for all people who are facing such questions on how to handle team and people in general. – Narendra Pathai – 2013-09-14T10:07:45.887

Answers

331

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.

bethlakshmi

Posted 2011-07-14T14:13:18.677

Reputation: 7 465

1Wonderful links, especially the second one. – Reid – 2011-07-14T16:30:32.823

31Great answer! Well worth the time to read. – Falcon – 2011-07-14T17:02:27.660

14The problem with introverts is that we don't always remember that extroverts are not also psychic. – MirroredFate – 2011-07-14T17:34:48.167

2oh wait, this wasn't a blog post - I'm still on programmers! Good job! – Xeoncross – 2011-07-14T17:43:19.157

17There should be a +10 button somewhere... – Marjan Venema – 2011-07-14T18:32:05.983

@bethlakshmi, as always you put in earnest efforts to stretch so as to communicate things as clearly and comprehensively as possible. Your answer is certainly worth being a wiki. – karthiks – 2011-07-14T19:08:12.230

3Thanks gang! I can't say how nice it is to see comments like these! It keeps me writing! :) – bethlakshmi – 2011-07-14T19:10:25.213

1As a project manager, you should track your team's habitual progress of estimate vs. actual time to completion. Using very simple math, you can make an educated guess at the actual completion time based on your team's track record when giving estimates. Keep in mind that no estimate will be 100% accurate. It's also a good idea to break down the units of work being estimated into as much fine detail as is possible. As a developer, I strongly recommend some of the Agile management practices mentioned below as a way of improving the accuracy of project estimation. – RMorrisey – 2011-07-15T03:24:31.660

Thank you very much, this is indeed a great answer. – AgentSmith – 2011-07-15T11:39:14.480

3Some teenagers, communicating via voice, won't ask other teenagers out or talk about relationship stuff. Give them text messages and they'll say ridiculously intimate stuff. To a similar extent so will we all. This is why text messages are so ubiquitous when it's so much harder to communicate over them. Point is, opening up all the channels is a necessity. – Kzqai – 2011-07-16T20:55:07.793

@Marjan, agreed 100%. Where's that stupid +10 button? – Fabricio Araujo – 2011-07-17T23:37:57.837

+1 just for the "don't force the devs to conform to your way of communicating". I want a +10 button too. – Michael Kjörling – 2011-07-18T08:09:26.297

+1 just for Rands, now I don't have to post an answer :) – Benjol – 2011-07-20T08:47:33.093

+1: great answer! – haylem – 2012-03-02T19:03:57.227

"listen for ambient noise, word choice and the space between the words...look for word choices - they are often as important as the words themselves" Wow, you are quite sensitive to subliminal messages! One should note that you cannot pay too much attention to this, because you might jump to the wrong conclusions. – bobobobo – 2012-05-03T01:27:44.063

Agreed! I'd call that "attempting to be psychic and failing" - when in doubt, it's good to check in words. – bethlakshmi – 2012-05-04T17:03:56.643

161

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.

Joris Timmermans

Posted 2011-07-14T14:13:18.677

Reputation: 8 166

91+1 "mistaken estimates" – S.Lott – 2011-07-14T14:42:02.710

5This points out that developers often need to be more assertive. Many are afraid to talk to "the suits", and so they never raise the issues that need to be raised. Asking managers for stuff, even demanding it, is part of the job. – Kristopher Johnson – 2011-07-14T15:52:40.453

7At the same time, developers may not realize management is interested in listening, and so they don't bother. – jhocking – 2011-07-14T16:23:35.040

5The old rule-of-thumb for turning an estimate into a delivery-date is to multiply it by 400%. Estimates often forget to include all the ancillary coding, and it's critical a development manager knows how much to pad estimates rather than trying to eek out more accurate numbers in the first place. – STW – 2011-07-14T16:33:12.703

2I understand your point, but programmers don't work in a vacuum. Roll outs have to be planned, payments scheduled, ads bought, documentation printed, bandwidth purchased, all of which need hard dates. Programmers have to understand that a bad estimate from them can kill a business just as surely as a bad bid by a contractor can kill their business. Certainly "estimates" decreed by management in order to meet business requirements are poison, but there is just no way to avoid the fact that folks downstream from the programmer have to rely on their estimates. – Charles E. Grant – 2011-07-14T18:15:05.600

11@Charles E. Grant: "all of which need hard dates"... While true; early estimates are mere fantasy. A manager who makes serious cash commitments without working software in hand is acting imprudently. Blaming developers for inaccuracy misses the point. Making commitments based on "estimates" is often bad business. – S.Lott – 2011-07-14T18:19:50.350

4@-S.Lott, boy I've worked at a major shrink wrap software firm, and a couple of small software contractors, and I've never seen any of them use your suggested approach. It certainly would reduce the risk for the company doing the development, but it ignores the risks for the customers: competition, market windows, regulatory requirements, etc. I've never seen anyone offer a contract for custom development without a schedule specified. Would you hire a contractor for a home remodel without getting some sort of commitment as to how long the job will take? – Charles E. Grant – 2011-07-14T18:32:56.427

1@Charles E. Grant - don't get me wrong, project managers at my firm also have to base project budgets, timelines and projected ship dates on estimates, but I would never, ever call an estimate "mistaken", just "off". You have to factor in the odds that an estimate is "off" and by how much. This is also why any estimate here always has two values: the "66% chance" and the "90% chance" estimates. The variation between those two numbers is an indication of the risk and/or uncertainty in that particular topic, and is used to pick out those items that need more drilling-down. – Joris Timmermans – 2011-07-15T06:53:48.917

@jhocking - the only purpose of management is to listen and remove those obstacles from development that development themselves cannot solve. This should be a given. If management is actually not interested in listening then you should get out as fast as you can, because the company you are in is run by the management school "management by wishful thinking". – Joris Timmermans – 2011-07-15T06:55:43.890

Another +1 for highlighting the bizarre concept of "mistaken estimates." We had similar problems where I work. We developers gave estimates based on +/-, e.g. if we said 5 days, then it was reasonable to suppose the task might take 4 days or 6. The trouble was, our manager was taking our estimates this way: If we said 5 days, then the task would take no longer than 5 days. Frankly, he was a very poor manager for not making this clear at the outset. We had to switch to severely overestimating to account for his idea of what an estimate means. – Kyralessa – 2012-01-11T18:09:43.637

70

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.

Morons

Posted 2011-07-14T14:13:18.677

Reputation: 13 927

7+1 well said. (extra characters to make up to limit) – sevenseacat – 2011-07-16T05:12:32.943

10Then again, maybe the senior developer was a tool, and all the other devs were just waiting for him to leave. There's a lot of undisclosed context in the question that you're assuming you understand. – naught101 – 2012-06-07T06:06:40.683

"No one tells what is wrong" , absolutely true. – Buzz – 2012-10-30T12:18:57.437

37

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.

Vitor Py

Posted 2011-07-14T14:13:18.677

Reputation: 4 455

7+1, Mythical Man-Month. That book might be old, but it is never outdated. – David Hammen – 2011-07-15T01:21:55.037

Plus the Anniversary Edition adds some excellent new material for the nineties. I hope they produce a 40th Anniversary Edition in 2015. *8') – Mark Booth – 2011-07-15T16:00:18.670

3Nothing kills morale faster than lies. The biggest lie management says is "You don't need XYZ to do your job." How can they possibly know better than you? Therefore they lie, therefore there is no trust, therefore no morale. replace XYZ with "monitors, software, faster hardware, servers, food, quiet working area, large amounts of desk space, white board, break room with other-than-sugar foods, flexible schedule, etc..." When management doesn't come out and ask specifically: "what do you need to get your job done well, I mean it, I'll get it for you" they implicitly don't want to. No morale. – Christopher Mahan – 2011-07-16T01:24:14.257

Another book worth looking at is Peopleware, by DeMarco and Lister. If you can internalize what's in there, you'll start building much better relationships with your teams. – Alger – 2011-08-13T03:16:52.857

26

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.

S.Lott

Posted 2011-07-14T14:13:18.677

Reputation: 42 136

3I think Agile can help, but it certainly sounds like there's a communicate problem here that needs to be fixed. He honestly didn't know bad machines were causing legitimate pain. Thats on the developers for not raising the issue. – Andy – 2011-07-14T16:02:02.133

@Andy: A toxic organization is often the root cause of bad communication. People want to communicate. However, a higher-level manager can easily prevent this by rewarding silence and punishing communication. – S.Lott – 2011-07-14T16:46:50.197

3@S.Lott: Not everyone wants to "communicate". – MirroredFate – 2011-07-14T17:33:38.137

3@S.Lott: Not everyone wants to communicate. And even if they do, not every communicates effectively, which sounds like the case at this organization. – Andy – 2011-07-14T19:39:21.980

1"True communication is possible only between equals, because inferiors are more consistently rewarded for telling their superiors pleasant lies than for telling the truth." – Benjol – 2011-07-20T09:01:11.977

22

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.

Falcon

Posted 2011-07-14T14:13:18.677

Reputation: 16 272

Very good quote: "I take all the blame and I share the fame with them." – Jared Burrows – 2013-09-11T05:43:42.790

20

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 :)

karthiks

Posted 2011-07-14T14:13:18.677

Reputation: 450

2Yes, he certainly should be a good person. I hate bad people. – Xeoncross – 2011-07-14T17:45:25.223

Could back-fire explosively, too ;) – Wayne Werner – 2011-07-14T18:56:19.547

23Don't use acronyms like that one to communicate with your underlings. – RMorrisey – 2011-07-15T03:19:57.447

+1: Great answer. – Jim G. – 2011-08-13T00:38:23.210

16

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.

KeithS

Posted 2011-07-14T14:13:18.677

Reputation: 15 504

1What is the Type-Y personality trait that you are talking about? Have a link for more detail on it? – tylermac – 2011-07-14T17:23:33.367

3Less Type-Y personality and more Type-Y management style. Look up Type X vs Type Y managers; basically, Type X managers believe people are primarily motivated by the money a job provides, while Type Y managers believe people are generally motivated by fulfillment a job provides. The truth for most workers is somewhere in between, but most managerial styles lean one way or the other. – KeithS – 2011-07-14T17:28:53.797

3The proper term to Google is Theory X and Theory Y. – Mark Canlas – 2011-07-14T22:05:20.743

+1 most thought and meaningful answer here. – AndHeCodedIt – 2011-07-15T19:44:06.683

11

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.

Philip

Posted 2011-07-14T14:13:18.677

Reputation: 6 105

Motivation is well worth looking at, I try to cover many of it's point in my answer to a related question: http://programmers.stackexchange.com/questions/87321/what-is-the-best-way-to-incentivize-a-team-of-developers/87354#87354 – Mark Booth – 2011-07-15T16:40:12.460

8

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.

PSU

Posted 2011-07-14T14:13:18.677

Reputation: 1 089

+1 for "telling them what you just told us." – Ben L – 2011-07-14T15:37:36.530

7

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.

JeffO

Posted 2011-07-14T14:13:18.677

Reputation: 33 459

3+1 for accepting feedback and acting on it. Possibly the most important things a manager can do. – PSU – 2011-07-14T14:51:16.817

1The unstated implication of this answer is that you've gotten the ball rolling on accepting and acting on feedback, so keep doing the right thing. The very real communication problems you brought up probably mean your developers were pleasantly surprised to learn you're one of the great managers who accept and act on feedback; keep responding to feedback well and they'll keep giving you more feedback. – jhocking – 2011-07-14T15:43:30.970

7

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.

Codism

Posted 2011-07-14T14:13:18.677

Reputation: 1 068

5

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.

wolfgangsz

Posted 2011-07-14T14:13:18.677

Reputation: 5 121

5

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.

Morgan Herlocker

Posted 2011-07-14T14:13:18.677

Reputation: 9 567

1+1 for donuts. We actually use cake. We have a once monthly cake that is for everyone's birthday that month (and just because if there's no birthdays that month). Not only does everybody like getting cake, but getting together and eating it also provides an informal chance for everyone to get together and talk. That includes management. My manager and his director both come to these and just talk like everybody else. That helps a ton with communication because you see them as normal people and not as managers. They also overhear when two devs start talking about slow computers over donuts. – Tridus – 2011-07-14T22:03:43.457

@Tridus - yeah, every month the CEO and COO at our company take whoever had a birthday in the last month out to dinnner. Not everyone takes them up on it, but in a company with about 250 people and me being a lowly grunt its pretty cool to sit down with my boss's boss's boss's boss and have him pick my brain on how we could operate more effectively. – Morgan Herlocker – 2011-07-15T13:26:17.593

1+1 for "Every issue I have can be solved by handing me a donut, with the exception except unrealistic estimates." – KK. – 2011-07-16T13:11:36.793

4

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.

JB King

Posted 2011-07-14T14:13:18.677

Reputation: 16 305

3

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.

David

Posted 2011-07-14T14:13:18.677

Reputation: 615

3

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.

Jesse Greathouse

Posted 2011-07-14T14:13:18.677

Reputation: 1

2

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

John Christensen

Posted 2011-07-14T14:13:18.677

Reputation: 203

2

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

Stephen Bailey

Posted 2011-07-14T14:13:18.677

Reputation: 2 096

1

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.

Paul Nathan

Posted 2011-07-14T14:13:18.677

Reputation: 8 318

1

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.

dodgy_coder

Posted 2011-07-14T14:13:18.677

Reputation: 1 008

1

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 :)

Martin S. Stoller

Posted 2011-07-14T14:13:18.677

Reputation: 348

3That's assuming that the problem is with the programmers and not me... reading the answers above has given me great insight already. – AgentSmith – 2011-07-14T15:42:18.087

1

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.

huitseeker

Posted 2011-07-14T14:13:18.677

Reputation: 154

1

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

Graham Borland

Posted 2011-07-14T14:13:18.677

Reputation: 571

2Far from all developers enjoy this. Some have other commitments that make it difficult, even. – Michael Kjörling – 2011-07-18T09:26:12.373

+1: Ya know... This isn't a silver bullet (and you never said that it was), but it still might heal wounds. – Jim G. – 2011-08-13T00:53:43.093

0

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

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

Jonathan Cline IEEE

Posted 2011-07-14T14:13:18.677

Reputation: 888

0

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.

user93353

Posted 2011-07-14T14:13:18.677

Reputation: 71

0

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:

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).

Thomas Owens

Posted 2011-07-14T14:13:18.677

Reputation: 49 967

-1

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.

Richard

Posted 2011-07-14T14:13:18.677

Reputation: 357

-1

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

Rahul

Posted 2011-07-14T14:13:18.677

Reputation: 1

1-1: You're prescribing very "mechanical" remedies and you're treating developers like automatons. – Jim G. – 2011-08-13T00:50:32.600

-1

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.

lepine kong

Posted 2011-07-14T14:13:18.677

Reputation: 1

-1: Deming won't solve the OP's problems. Remove all Deming references from this post. They're not at all applicable. – Jim G. – 2011-08-13T00:56:49.123

-1

Well, first thing to spend some time with your team, then motivate them to improve skills, make them understand, that the project will be a milestone in everyone carrier. Spend time out of official work with team once in a month. Feel free to appreciate their initiative and effort. Its just a matter of behavioral change. BTW most of project have critical and worst face, but its the area, where a manager need to prove his patience and ability. As a manager your responsibility is not just to manage a team/project, you are more than that. Basically you are mentor for them, a teacher for them. Wish you a good luck!!!!!!

Rudra Gautam

Posted 2011-07-14T14:13:18.677

Reputation: 1

-3

My first thought is; tell me Your company name so I can short it.

You have horrible management issues and have zero trust with developers. At least You've figured it out before the company went down in flames.

Start by reading "Deathmarch", it sounds like the kind of projects You're running, then You can start understanding just what kind of dynamics You're working with here.

John J

Posted 2011-07-14T14:13:18.677

Reputation: 1

-4

As far as I know, you need to give importance to every thing in this world.Nothing is unvaluable.The things in the world are useful for something.So, we need to give respect to all and we need to give importance to everything.Dont hurt any one.Keep yourself in other shoes,if it hurts you then probably it hurts others too.

kiran

Posted 2011-07-14T14:13:18.677

Reputation: 1

-4

You ask some very good questions. A great first step toward improving your relationship with your team would be to share with them what you've shared with us.

Caleb

Posted 2011-07-14T14:13:18.677

Reputation: 34 453

Asked: 2011-07-14T14:13:18.677

Viewed: 16 910 times

Active: 2013-06-12T12:28:50.077