This one is taken from here. It is really, really useful (and true to an extent) 🙂
Communication breakdown
A new manager joins the company, or an old one gets promoted, and the first thing they are eager to do is push for improved communication. Sounds familiar? Later, as manmonths go by, the effort fades away until a new guy steps in. In this post we try to break down the aspects of that vague communication concept, the real value of it, and the little tricks JOTGs can use to take advantage of the situation.
Purpose
Most technical problems come down to human problems. Therefore communication is still fairly important even in a sterile engineering environment. It’s either your buddy has already solved the issue you are dealing with, or has the quick wit to help you solve it better, or someone wants to share new ways to do routine work twice as effectively, or your manager announces information you have no access to, like upcoming orgchart changes, or you need to agree on interfaces exposed to other developers and avoid duplicate work. Multiple purposes, seemingly, but it all comes down to faster development (reduce time to market, i.e. make more money), better design (save time from support and bugfixing—save money), and protect information (make announcements on a need-to-know basis, prevent data leakage to competitors, protect money).
But why do new managers like communication so much and old ones seem to slowly get to ignore it? The key is, communication must be demonstratable. New hires/promotes tend to have a desire to show off their effectiveness, both to senior management and to ordinary employees. Once they channel their workflow and gain recognition, they become happy with the status quo and just go with the flow. Founders and near-sabbaticals may even seclude themselves in a remote room, talk only to their direct subordinates, and be ignorant about the outside world. This is natural, just maintaining profit along the path of least resistance.
Dealing with
So, how are we to react to newfangled overlords who at every meeting remind us to communicate more? We do as they say. Actually, we communicate just as we have until now, but more visibly. Remember this is about visibility, and not really about exchanging useful information. It’s the new managers seeing our professional conversations and it’s us presenting new managers to the outside world as facilitators. This means CC them in emails, write some design documents from an abstract point of view, draw some charts, discuss the engineering process with them. They love it. They love somebody talking in their language, they enjoy words they understand. As a side effect, you can appear smarter in their eyes. The important thing is, they will let you be once they are convinced that everybody can see that they’ve helped somebody talk to somebody.
In rare cases, hypercommunicitis may persist even after being treated with pages of managerspeakish spam. You should fall back to flooding with stupid questions then. It always works, but the downside is that when you ask stupid questions, you look… just an ordinary human resource, capable of being fine-tuned to do more work for less time (and you know what time translates to). In a team of trusted colleagues you could make a DDoS of questions, while pretending to be discussing important topics among yourselves.
Done right
Techies should understand, and most of us do, that talking to a human is fundamentally different than interacting with a computer. This is nothing new. Humans are complex. You cannot type commands, expect strict execution of an algorithm, and get a clear greppable output. Our languages are imperfect and we have emotional interference. You should communicate just as much as you feel is necessary. To make the most of a conversation, prepare. Plan some time to read about what you will be discussing. In the long term, learn common techspeak like design patterns and the jargon file. Do not pay attention to how much or how visibly you speak, but how fast you get a correct mutual understanding and how useful the exchanged information is. It’s also important to socialise with colleagues, to upfront remove the psychological barrier of starting a conversation.
Examples
Mgmt: We need to communicate more.
Tech (bad reply): But we have regular standups every morning and we already discussed the impl of ShitUtils with John by instant messenger…
Tech (good reply): OK, can we schedule another meeting this afternoon and reflect that in the project plan? I can put you as well on CC of our email thread with John.
[Analysis: Ask for planning of meetings, those should not eat up development time. Send an email or two per day with CC, do not burst emails because Mgmt will not read them all anyway and will still ask you for communication on the following day.]
Mgmt: Let’s reuse code. Why don’t you ask Smith about their team’s impl in
projects/AcmeCrapware/branches/1997/src/shared/ShitUtils.c
Tech (bad reply): But that’s ten years old and the guy who wrote it left the company. And Smith is a retard. It will be easier for me to write it from scratch, it will take no more than two days.
Tech (good reply): I’ll ask Smith and evaluate their impl. […] I asked Smith yesterday, but their ShitUtils do not correctly handle the latest version of the Camelturd file format, and according to our requirements we need to support it. Why don’t we spend three days to research the PooTools LGPL library and save development time?
[Analysis: Other people’s code usually sucks. Small util libs take less time to write from scratch. You should always bargain for time.]
Mgmt: When and how do you plan to design this new “excremental search” feature?
Tech (bad reply): It will use a red-black tree to optimise queries and update
the tree incrementally. [Mgmt looks confused by in-/ex-] John must decide if we can include it in now, but he is on vacation, so we do not have active tasks for today.
Tech (good reply): We will reuse an existing incremental algorithm, and implement an adapter to turn it into an excremental one. I will have to talk to John. […] Oh, I got an out of office reply from John, so we must abandon what we did for the 2.0 shitment until we start working on 3.0
[Analysis: If the manager is not informed, it’s their fault. This includes both knowledge about people in the company and technical incompetence. Never tell a manager you have no work to do. Do not hesitate to use buzzwords for deception.]
Viewed 11927 times by 3826 viewers
