Years ago I was with my uncle, an extremely technically adept retired Coast Guard officer, bleeding the water out of a fuel line for a small outboard motor. He told me to turn the petcock counter-clockwise to open it and I asked him whether that’s counter-clockwise looking down at it or up at it. He pointed out that ships have been lost for that reason.
Communication is hard for *everyone*.
Communication has long been something of a challenge for me, so I’ve learned to keep my eyes and ears open for ways to do it better. I also like frameworks and systems, so I was naturally drawn to the information Nikki (Heise) Evans (see her company’s website) presented during a recent online series of project management webinars organized by the Project Management Institute (PMI) regarding a new (to me) way of thinking about communication styles and motivations.
Note that the Goal Setting quadrant should include bullets for Vision, Options, Bottom Line, and Discussion. I apologize for not capturing the optimal rendition of this slide.
She describes two different preference axes: one for speed (moves carefully vs. fast paced) and one for results vs. relationships orientation. The latter could also be thought of as engagement vs. solution, product vs. process, or people vs. things. Where one falls on the two axes points to a preferred concern orientation as one works. This works like many different personality tests.
If one prefers to move quickly with a results orientation, one is said to have a goal setting outlook that primarily asks what the focus is. If one prefers to move quickly but with a relationship orientation, that points to a lifestyle outlook that tries to make everyone comfortable. If one prefers to move more deliberately and with a relationship orientation, that indicates indicates a stability outlook concerned with how different ideas will sound. Not surprisingly, I prefer to proceed somewhat deliberately and with a results orientation, which is described as having an information outlook that tries to identify what customers need.
I am always an analyst first, and then everything flows from that. Even if I don’t appear to be oriented toward people in an obvious way, developing excellent solutions is ultimately in service of meeting their needs, so we see everyone is trying to get to the same place.
It is important to note that good leaders and analysts will be able to adapt to conditions, team members, and customers as needed, and that these categories of outlook are not hard and fast, but only serve to understand how one is likely to proceed when starting out. Over time, effective communication, analysis, iteration, feedback, and correction should lead individuals and teams to create similarly effective solutions. I wonder, however, if Nikki and and her colleagues have noticed that the nature of the solutions and the problems typically encountered tend to vary with the orientation of different types of leaders and approaches. I believe I will ask them that very question, and I will report back when I learn more.
Noting my affinity for frameworks and systems, I’d like to see where this fits in with similar insights made by others. Let me list and briefly describe some of them, and then compare the present insight.
I first encountered the above communication model in a leadership school in the Army, and I have encountered additional materials on communication and information theory since (for example, this one was interesting). This started to give me a feel for how complex communication can be and the problems that can be encountered.
From my work in distributed real-time systems I learned that distributed, real-time system communications must often be retried until success is achieved. Given the number of communication channels that may exist the effects of poor communications can be highly problematic.
This is why my engagement and analysis framework has evolved the way it has, and how I’ve chosen to represent it. The circles in the top figure represent the iteration within each phase of all the relevant activities and communications as they proceed to completion. The two-way connections between the circles represent the iteration between phases both as the project moves forward as the effort progresses and backwards as subsequent discoveries induce changes in the understanding of previous phases. The lower image shows how the analysis process proceeds in the context of a project management effort.
A gentleman named Dave Thomas, who was one of the original authors of the Agile Manifesto, gave a well known talk provocatively titled Agile is Dead, admonished practitioners that the cottage industry that has grown up around Agile and Scrum (and Kanban and so on) is largely beside the point, and that what Agile should really involve is getting people to talk to each other and change course as necessary. It’s not that all the other things taught don’t have value; it’s that they’re kind of beside the point. All the practices (that came from the eXtreme Programming or XP oeuvre that was in vogue about the time the Agile Manifesto was written) are useful, but they aren’t the major innovation. They are things you should be doing anyway if you want to run an effective shop, whether you are consciously “doing Agile” or not. The real innovation was in seeking and incorporating feedback and correction purposefully, early, and often. In short, communicate more and better and act on it.
A gentleman named Matthew Green shared his extensive knowledge of Agile and its related practices at two of the recent Tampa IIBA chapter’s weekly certification study group webinars. His presentations and knowledge and speaking quality were exceptional and he made the best arguments I’ve ever heard as to why the various software development practices should be thought of as integral to the Agile oeuvre. His argument is that the the ability to react quickly and actually deliver value quickly is dependent on knowing and practicing the relevant development techniques. While I agree with his point and have complete respect (and admiration) for his skills and experience, I still view the practices as mostly separate and independent. ScrumMasters don’t necessarily need to know much of the development oeuvre, and Product Owners need to know it even less. (It never hurts if they do, of course.) The advanced techniques they teach in the Certified Scrum Developer track (as least through Scrum Alliance) make a worthy point of crossover, however. Somebody should know the development practices well, but it is somewhat specialized knowledge. ScrumMasters, Product Owners, and other team members do not necessarily need to concentrate on that knowledge. They have their hands full with other duties, after all. It should usually be enough for people to communicate with each other effectively so the necessary knowledge is shared and acted upon as needed. That, to me, is the essential thrust of Agile.
All that said, you are invited to review the meeting recordings here, and tell me what you think. Specifically check out the videos from August 23rd and August 30th, 2022 (BABOKStudyGroup20220823.mp4 and BABOKStudyGroup20220830.mp4). I believe they are sessions 50 and 51.
I encountered two more interesting frameworks while attending many dozens of business analysis Meetup sessions hosted by different IIBA chapters.
Kara Sundar presentation on Communicating with Leaders described different concerns of leaders in ways that may illuminate how to understand and communicate with them. This is similar to the framework Ms. Evans presented, as described above. I’m sure it will also affect the nature of the working environment those leaders create.
Kim Hardy’s presentation on Nice SDLC Cross-Functional Areas, by contrast, described how to build a team based on the concerns of the team members. Rather than building a team by gathering up people with skill-based job titles like Sponsor (Product Owner), Team Lead (Architect), ScrumMaster, Developer, DBA, UI/UX Designer, Graphic Artist, Tester, Business Analyst, Specialists in Security/Deployment/Documentation, and so on, one can identify team members based on concerns like Business Value, User Experience, Process Performance, Development Process, System Value, System Integrity, Implementation, Application Architecture, and Technical Architecture. One doesn’t typically recruit for people with the latter labels or titles, but this is a way to ensure that attention is paid to the qualities of the process and the solution. This should happen anyway, but having an organized way of thinking about can definitely increase the chances of success.
I have also had the privilege of learning about the Herrmann Brain Dominance Instrument, which can help managers communicate more effectively with team members. Other popular personality typing systems like Myers-Briggs and the Big Five provide similar insights.
At one point I thought that Ms. Hardy’s framework helped address the non-functional aspects of the solution while building a team by standard title was geared more toward the functional aspects of the solution. Most of the other frameworks and tools seem geared more toward aspects of the engagement and the environments in which they operate. I still think that idea has some merit, but it is not particularly important. In any case, I know all of these practitioners are very knowledgeable and experienced and can provide value across an entire spectrum of concerns, but each presenter has a limited time to advance a theme and make a limited but powerful point. I think all of these insights provide valuable tools for improving communication and mutual understanding.