In June 2013, Australian Chief of Army Lieutenant General David Morrison released a powerful message about demeaning conduct and harassment. This video has nearly 1.8 million views. Take a moment to look at it. What makes this video so powerful?

Watch the General’s body language. “Earlier today, I addressed the media, and through them the Australian public…” he starts out flat, but his frown starts to deepen the more he speaks. When he says, “By now I assume you know my attitude to this type of conduct,” he raises his chin in a sign of his authority and distain for the conduct he’s speaking about. “If that does not suit you, then get out!”, his eyes widening and head moving, indicating strong emotion. “I will be ruthless in ridding the army of people who cannot live up to its values.” Eyes narrow, fury and determination. Finally, an expression that can only be described as serious, “If we are a great national institution, if we care about the legacy left to us by those who have served before us, if we care about the legacy we leave to those who, in turn, will protect and secure Australia, then it is up to us to make a difference. If you’re not up to it, find something else to do with your life. There is no place for you amongst this band of brothers and sisters.”

Wow. Did you get the message? Was it loud and clear? When working with verbal communication, non-verbal cues account for 55% of the message content. What makes the video resonate is the clear and palpable, yet completely contained, fury he feels at this event. Paralanguage, use of pitch, tone, pauses, etc. further enhance his message. That phrase, “I will be ruthless” is particularly powerful in emphasis. His belief in his words shine through. His demand that his personnel live up to better standards couldn’t be more clear.

To analyze it further on written/verbal and formal/informal axis, this communication was verbal, but was it formal or informal? It was an official statement, released by the Australian Army. He was dressed in uniform. This was a formal communication, but lacking in some most formal trappings. How might this appeared differently if he was in formal dress uniform, as if giving a report to Parliament? Might that have provided the wrong image? The every-day barracks uniform was more appropriate when addressing the rank-and-file members of the military, yet still provides distinction to the civilian audience.  He did wear a more formal uniform in speaking with the press.

Let’s review this communication on the five elements I spoke of in my first article:

• Goal – Make a clear statement about repugnant activity and demand change
• Message – Women are service valued members; demeaning and harassing conduct will not be tolerated
• Audience – The public and members of the Australian military
• Medium – A video posted on a web site (we’re looking at it four years later!)
• Metric – No further incidents of this kind take place

You can look up more of Lieutenant General David Morrison, retired, comments at women’s conferences. He’s a powerful speaker. A lot of that power comes from his commitment to his message and the way that commitment shows in his delivery. The video is inspiring, and I have often used it when speaking about communication, not only for its instructional value, but to emphasize my own commitment to an inclusive environment.

For the second half of this article, let’s look at a project situation and talk through how we might use communication to coordinate activity.  Some version of this situation has been used by development teams for ages, and different version control systems use different methods to manage source code.

• Situation: Let’s say we have a sizable company producing an on-prem product. Code flows up from many development branches to one of eight group branches to the aggregation branch to the main branch. The aggregation branch moves to main whenever it builds cleanly and passes build verification tests. When the aggregation branch goes to main, those changes are pushed down into group branches by the build team. The code is tightly coupled, meaning that changes in one group branch may break code in another group branch. Thus, the aggregation branch is often broken and requires fixes after group branch merges. Sad-face.  🙁
• Stakeholders: The company contains 320 individual contributor developers (with a quarter of them formally dedicated to test) and 80 individual contributor technical PMs. The development team is divided into forty teams headed each headed by a lead, five leads report to a group manager, eight group managers report to the VP of Engineering. The technical PMs are dedicated to a development team, with 10 TPMs reporting to a TPM lead who reports to a group manager. A build team, part of an engineering tooling team reporting to a group manager, is responsible for producing all of group branch builds, the aggregation branch builds and the main branch builds. The project manager reports to the VP of Engineering. Marketing, finance, etc. are interested in the project, but not in code movement aspects.
• Goal: Your mission, if you choose to accept it, is to move code from group branches to the aggregation branch – while minimizing conflicts and maintaining the high-level project schedule. Refactoring code to reduce dependencies is not in scope.

How might you organize this?

One way to do this would be to create a calendar for aggregation branch integrations with the goal of reducing conflicts through intelligent scheduling. If you know one branch always breaks other branches, isolate its integration.  With a web based calendar (pull communication), groups could put their chosen integration dates on the calendar ad-hoc, or could be scheduled specific days for predictability. The build team could produce daily mails (push communication) indicating progress and resolutions for integrations, build results and build verification test results. The build team could also hold a daily integration meeting (interactive communication) for build, reviewing incoming payload, possible conflicts, possible delays, reviewing build breaks, assigning engineers to integration failures, etc.  The project manager could hold weekly project hot issues meeting (interactive communication) for the Engineering VP and group managers (along with emailed meeting notes with action items, emphasizing verbal communication with written).  The project manager could also send  a weekly status and direction mail for the whole team (more push communication). Graphically, it would look like this:

 

What if the company had more than one product division? This situation could be more complicated if a third of code and functionality came from outside this division. It would be necessary to add some communication to ensure those groups were on track and their code products could be integrated properly. This division’s project manager’s discussions with that divisions’ project manager (and review of their status communications), along with a bi-weekly meeting of all contributing group managers, might suffice – or it might not. What if this project is only part of a larger integrated project, and there are ten more divisions just like yours? The complication increases exponentially.

Consider that this example is merely one part of a project, code flow.  There are many ways to structure code production (business analysis) and equally as many ways to manage communications on the process (project management). There’s also managing what you are producing, is that production happening according to plan, is that product meeting expectations, and many other aspects of managing the project.  We spent no time talking about marketing teams, finance requirements, or other project matters. A communication plan must account for all stakeholders and all activities, and is vital to monitoring and controlling an overall project.