How Communication Factors In To Production | Targetprocess - Visual management software

Having published several posts on organizational culture and communication in agile teams lately, I feel compelled to write more. Here's why. Looks like there's a gap in people's minds when it goes about cultural- vs. production-driven thinking. The very presence of this "vs." shows that task-oriented project managers, product owners, IT directors and other people in the positions of authority have a loose attitude toward culture, time and again. They consider it a nice-to-have extra, while their main focus is on what appears to be those "real" factors that impact production: the count of user stories done, or bugs fixed, etc. In general, they want graphs and reports for everything and anything. However, as it comes to a candid retrospective analysis, the bottomline reasons go past figures and find their roots in the organizational culture.  Alas, there's no way to read it from a graph, as to how culture flaws and faulty personal interactions might result in a late release. Even more, considering this innate unquantifiability of those, there's even a greater need to factor communication in. Keeping organizational culture polarized from production is a luxury one can't afford, as it comes at a cost. Not an ethereal, but quite a tangible one.

Personal interactions wouldn't be all that important, if software development wasn't a sum of creativity and knowledge work. While one can formalize processes and stats on the machine-like actions, the quantitative metrics, the human aspect can hardly be formalized at all. The best attempt that I've seen so far is this:

begin friendship algorithm

One can draw a parallel between unattended cultural bottlenecks and impediments to the development flow. Any unspoken concern or unaccounted for trait of personality may impact the production results big time. Here are some examples that would help make sense of this viewpoint and trace the dependency between cultural traits and tangible costs.

As a brilliant UX designer, you are working on some concept, at a hypothetical software development company. Your work is very important to the company, and you are in a team with other UX designers.  Anyone involved in UX design knows that it takes many sketches and drafts to come up with a final approved solution. Here's what might happen next. This person has put everything that she has into this design, and is eager to see her work shipped. However, if the approval decision is made by a group, there are some nuances. On the one hand, a group can make a positive contribution.  As they say, "many heads are better than one." But what if this group approval takes too long, and it's essentially not about the major flaws, but about some tiny details, that when communicated to this brilliant designer might leave her feeling as if the peers are too picky? What if debating over a design becomes too tiresome, day after day? A very unspoken of case, but what if this group has lost their focus and — a very bad scenario — their feedback comes wrapped in an unconscious pursuit to emphasize their own knowledgeability and authority in approving this design concept? This UX super hero will get discouraged, burned out intellectually and emotionally and.... stakeholders know that good UX designers are not easy to find. That's where it might come to a crack that would leave this person dissatisfied with their job. In this case, organizational culture and personal interactions worked to the negative, diminishing the company's assets.It was counterproductive to stick to the decision-making model (the group approval) as it didn't resonate with this person's creative style. Could be, just to continue with the storyline, that this UX designer prefers one-on-one interactions and is better off dealing with one person in the position of final approval, who would get the condensed meaningful feedback from the group to this person.  The same example can actually go for developers, as they take group decisions about an app architecture, framework, code guidelines, etc. One other common concern about group decision-making is that it favors assertiveness of expression over the value of contribution. Someone with an assertive personality style would catch the group attention easier than someone who is less self-confident, but nevertheless has some valuable ideas to contribute and might keep them unspoken, if the group chooses to skip the contribution from this person. That depends on the organizational culture.  Then one can sit and count the cost of solutions that have been left unattended this way. Such losses can be directly attributed to the flaws in organizational culture.

I'm certain many of you might recall similar cases, tracking the outcomes of what appeared to be just glitches in communication. It takes some thinking and weighing choices to maintain organizational culture that organically arises from the context of the tasks at hand + unique personalities. Even when one spends some extra time on that, it pays off as the whole organization will benefit more from a few wise decisions than from too many erratic actions.

Related articles:

Non-Violent Communication for Agile Teams

Non-Judgmental Communication for Agile Teams

Are You Dumb?

The Dangers of Small Talk

Why Fast Is Slow

You can subscribe to our monthly newsletter here:

Thank you!

Сheck out latest blog posts:

Start your free trial

Enter your email
By clicking "Continue", you acknowledge and agree that we will process your personal data in accordance with our Service Privacy Policy and Terms of Service.

We’ve sent you a confirmation e-mail — please, go check it.

Or get a live
product demo