Like many here, I'm sure, my company has a person that acts as liason between development and most other areas of the company, as well as our clients. Most communication regarding new releases, fixes, known issues, etc. goes through this person.

However, because this person is not a developer and not deeply involved in the development projects, sometimes what developers submit for dissemination is edited for brevity or simplicity, and in the process, key details or subtleties are lost.

I've been pushing for a review process that includes the author of the original document, whatever it was, before the material is released. Among other things this would, I feel, allow the person with the greatest technical knowledge about what's being talked about (the one who actually wrote the code for the new program, feature or fix) to weigh in on anything that may have been oversimplified or been given a factual error by the editing process.

The person handling the communication, for their part, feels that the problem is education; the person is relatively new to the company and doesn't have extensive experience with all of the software applications and other products that development produces and supports. The person feels that as they gain this experience through training and reading the material that comes through their hands, the problem will resolve itself. They also feel that the back-and-forth would waste time.

I think there's merit both ways. What do you guys think?

  • 5
    I would say that the results from a review would be educational to the person handling the communication. A great way to learn what's important to the devs :)
    – Oded
    Sep 28, 2011 at 20:13

3 Answers 3


I'm not sure that the two sides of the debate are really saying different things.

If the developer that writes the release notes reviews the edited version before they go out, that feedback is one of the most efficient ways for the coordinator to learn about all the applications that the company produces and supports. That will help the coordinator learn about where there is complexity in the product line and where it is easier to summarize and simplify descriptions. Over time, as the coordinator learns what they can simplify and what they cannot, the developers are going to spend less and less time reviewing the documentation so less and less time will be spent on the back-and-forth. Once the coordinator is completely up to speed, developers will probably give a casual glance to the edits before approving them in the vast majority of cases.


So agree to stop having the reviews when the reviews stop finding anything useful. However, in my experience people come to value them after a certain amount of time. To help at first, make it clear that reviews aren't an indictment of any individual, just a recognition that diverse viewpoints tend to create a stronger outcome.


pushing for review process that includes the author of the original document, whatever it was, before the material is released

Word pushing somehow makes me feel you're experiencing certain difficulties in getting there, right? If that's the case, I'd prefer instead pulling a reverse process of reviewing the documents past release.

That pulling way is an easy one - one generally doesn't need approvals to just review released document and pass their feedback. And you can even keep a nice track of it without resorting to someone else outside of dev team. Just use your issue tracker (I assume you have one, don't you?) to collect the data.

  • "Issue #1234 created to review Memo 666 and provide feedback. - Issue 1234 assigned to Bob Programmer. - Bob Programmer spent 2 hours on analysis requested per Issue 1234. - Bob updated Issue 1234 with a copy of mail Memo 666: dev team notes sent to Jane Liason CCed to dev team, containing 56 corrections, clarifications and amendments. - Issue 1234 closed."

On a related note, lost details or subtleties might be not as severe issue as you perceive. I mean if you convince that liason guy that her prior message missed something really important, it might be easy for her to pass the correction. This is especially true if that guy specializes in communication.

  • I once have been closely working with marketing pro and she demoed me some of the typical tricks they use in communications practice. Like saying assertive things that turn out easy to dismiss later. Or like phrasing ruthless corrections of dumb mistakes in a way that sounds like expanding of what was previously said. Pretty amazing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.