How often should a programmer communicate with management?

Question

I struggle with finding a good medium on communication. In our jobs, it seems like it's very easy to get lost in code and lose track of time. It also seems kind of ridiculous to send out updates for every tiny task. Even though I am working very hard on getting things done, in a company that has very active communication between other branches, it tends to look bad for me when I'm not constantly updating my status. However, if I'm working on a 3-4 hour project, I'm not going to update management for every single line of code that I output.

Broad I know, depends on the people, company, etc, but what would be a good general rule of thumb for effective communication?

Answer 1

Agile methodology says you should have 2 week cycles on code development. I think the same is true on communication on big projects. I try to have a major communication every 2 weeks. That includes the status I have on all of my projects and everything. This can be in the form of an email, phone call, or face to face. The only reason to communicate more often than that in my opinion is if you have run into a road block and need your managers help to overcome it or if you are working on a project or task that they need feedback on when completed. In general this keeps unneeded communication to a minimum.

Another approach is to go see your manager directly and ask them what type of communication they want and how often. In general good managers only want updates when there are major issues or on a weekly/monthly interval. You need to discuss with them what is enough to keep them in the loop but not waste your or their time.

Answer 2

Ultimately, lots of communication is good, but if you're in the zone (and believe me, I know how hard it is to come out of the zone once you're in it) find other ways to communicate without losing flow.

Communication can take many forms. If you've got a list of features and can check them off in some way, communication can be as simple as firing off an email for every feature. If you have an issue tracking system, communication can be as simple as updating the issue when you fix/implement it.

Answer 3

To update business stakeholders on your progress? I do this weekly.

To find out from business stakeholders more details about what I need? Several times a week, sometimes several times a day, always either scheduled or impromptu over instant messenger.

To talk to a project manager? As often as it takes to make me more efficient.

Answer 4

You need to understand why managers need your communication. I have run development teams in the past, and I am currently a coding grunt, so I have seen both sides of the communication.

Managers usually don't have time to be intimately involved in your coding, mainly because they often also have to deal with other coders in your group, testers, senior management, product mangers, customers, human resources, etc.

Your manager has committed to deliver software, and has entrusted you with delivering some of it. Because (s)he does not have time to deal with you, (s)he needs to trust you. (S)he trusts you to focus on your work and deliver the software. If you mess up, (s)he will get hurt too.

The purpose of communication is to demonstrate knowledge of purpuse, to show focus, and to demonstrate results. Here are major forms of communication.

• A high-level design communicates that you know what you were entrusted to deliver. It doesn't have to be fancy. I am comfortable with rough sketches of a good data model, detailed key use-cases, and interfaces to 3rd party software.
• A development plan shows plausibly that you understand the steps required to deliver. I find that delivering working use-cases is best whether I'm a manager or a coder because it is an unambiguous way to independently verify completion of useful work.
• Regular status updates are good because they demonstrate focus. As a manager, I don't care if you have worked on this or that. I care about what you have delivered. From a developer's point of view, a good time to deliver a status report is when you commit code to source code control. Of course, you need good comments to show that you are delivering according to the plan. It is also a natural time to deliver because it represents an end to a "flow" or a period of being "in the zone".
• Flagging roadblocks is important because it demonstrates both knowledge of purpose and focus. A good manager will help you resolve these, but (s)he has to know about them.
• Dealing with bugs is a particularly sensitive time, because a bug represents a breakdown of trust because, in your manger's mind, you didn't deliver what you said you would. Being extra-communicative here is very important.

Over time, good communication will build up good trust, and ultimately it is the quality and quantity of your work that will determine your trust.

For that 3-4 hour project, you must make status updates when you start it, when you finish it, and on any code-commits you do in the middle (but if you don't, that's fine too).

Answer 5

This is an interesting question as it high-lights the verbal capacity of a programmer who ends up getting all-consumed in the process of coding that everything else seems "irrelevant", been there, done that with disastrous consequences!

DO NOT BE AFRAID TO SPEAK UP....

If there's something that is bothering you when you code...try talk to them in simplistic terms, ultimately, management do not want to know the intracies of pointer manipulation, TCP/IP stack, control re-freshes upon WM_PAINT, mapping network drive dynamically to obtain some data....you get the drift....

Speak clearly and concisely, be abstract....instead of saying something in wrt to say...pointer manipulation and seg-faulting, just say "There's some issue with the internals of the code that is causing it to misbehave, I'll estimate an n time to remedy this and get it documented and mark the issue resolved asap" where n is a quantity of time, be it minutes/hours/days/weeks or even worse months/years....

If you follow that pattern, that's what management wants to hear, if they hear the proactive approach, that is where you gain rapport and trust, and the level of trust will deepen. There is of course a 'slight hitch' with that...the management might end up piling on a load of trust which equates to responsibility for your coding....be careful there...do not flatter yourself in thinking "Gosh, they like me" at the same time burdening you with "responsibility" of the code....there's a fine balance between communicating and what they want to hear...by the way, I absolutely hate the concept of kissing one's ass in order to get ahead...DON'T!!!!

The moral and bottom line, (my being deaf and finding communication extremely frustrating and made to feel as if I'm put down or not being listened to, it's hard to deal with that because I could easily mis-interpret or mis-understand what's been said, that's my experience of it) speak clearly and do not be afraid to speak out no matter how big or small a coding challenge is or if the challenge is insurmountable and after all, that requires team effort. Share it with the team. I would be wary if nothing is shared and each in the team are in isolation and nothing being said...that's fishy....