It has been discovered that potassium is capable of being in two states of matter, at once. Potassium, and potentially other metals, can be a solid and a liquid simultaneously when extreme pressure and extreme temperature is applied. Some of the atoms of potassium are well formed and strong. They remain solid under these conditions while interconnecting chains of atoms melt into the disordered state that is liquid.
Processes, standards, procedures, responsibilities, and ownership can behave the same way.
The military way
My first experiences with adult responsibilities began when I was in the U.S. Navy. I finished my schooling and then entered the fleet only a few weeks prior to three other members of my work center. Less than a year later, 100% of my senior team members would be transferring to shore duty, leaving us newbies as the experienced technicians.
Until I became the work center supervisor and “senior technician” with less than a year of experience, several duties were transferred to us rookies, in increments. The universal truth that I learned was that the military does not mess around with ownership. Ownership to them is a very simple and binary situation. Either you owned it or some other specifically named individual owned it. Group ownership didn’t exist and there was never ambiguity about who was responsible. I had never heard the phrase, “role clarity,” spoken until I exited the military. Clarity existed, it did not need to be pursued.
On several occasions, I stood in front of someone who was either taking a responsibility of mine or giving theirs to me. We would shake hands, or some other gesture, and that marked the transfer of duty. It was common for a 3rd party to approach us, look me in the eye and immediately begin criticizing something that I had owned for less than 5 seconds. Pointing fingers back at my predecessor was ignored. No one cared how a problem came to be, they only cared about holding me accountable for solving the problem which was explicitly and formally transferred to me.
Dual states of existence
After transitioning out of the military, adapting to civilian life was not very challenging but it was an adaptation. There was a notable process to go through and adjustments to be made. As I progressed in my career from individual contributor to manager, I kept finding myself looking fondly back to my Navy days when many things were more clear than they are in my current situation.
Processes, standards, procedures, responsibilities, and ownership can all existing in multiple states simultaneously. The trick is to understand this and then identify it as a problematic state. A state to be avoided.
The conditions
Let us take a set of standards as an example. The development team must comply with automated functional testing and there are a set of requirements which attempts to define good enough. After using these standards for a period of time, you compile feedback from the team and identify both lessons learned and pain points.
At this first milestone, your standards are still in a singular state. Let us label it solid. The state, code named solid, has pros and cons.
This is where transparency and collaboration come to play. In the ideal situation, the team will be engaged in making incremental improvements and all voices will be able to contribute to brainstorming solutions to the various pain points of the existing standards. Some will reduce frustrations, others will improve quality, and some may reduce effort.
Making well-thought-out changes can take time and likely more than one conversation on the topic. This is where individuals begin to self define the desired state. At this milestone, each person has a similar but possibly different idea of what the state, code named liquid, looks like. Even if they all agree on what liquid is, there may be prerequisites for implementation which might not be satisfied yet.
The danger
Liquid may or may not be defined but the standards have officially transitioned into the simultaneous combination of both solid and liquid.
This is the point in which your existing standards and engineering discipline begins to breakdown. Many people will refuse to endure the pain points of the past since they know that the requirement will change, “any day now.” The false assumption here is that these are requirements of the past. In fact, nothing has changed. Conversations and brainstorming has occurred but no formal acceptance or acknowledgement of change has happened yet.
I have seen this problem cause teams to absorb 100% of the cons while realizing 0% of the pros. What was decent but flawed becomes nothing but an obstacle and impediment to all. The problems cascade, however. One management tactic I’ve seen employed as a prevention mechanism is to shutdown transparency and shutdown collaboration. If the team doesn’t know that we are working on a solution, they won’t jump the gun and undermine the existing process too early.
As they say, “here be dragons.” Taking this process through its nature course you end up with a team that feels ignored and shuts down your feedback loops. When you do come up with your solution, it too will be flawed. The team will tear it apart and show you how valuable their collaboration could have been, if it was embraced. They won’t own the new standards and will work to the tune of, “vicious compliance,” as us sailors called it. Malicious compliance, as Wikipedia refers to it.
The prevention
Rather than pull away from the team in an effort to prevent the dual states, we need to build a team culture who recognizes the importance of definitive state changes.
Similar to my experience in the Navy, we should build mechanisms to go-live with changes to processes, standards, procedures, responsibilities, and ownership. These changes should be public, formal, and celebrated in the light of continuous improvement.
Nothing about this means that change must be slow. It simply means that each change should be managed. Change management is important in a variety of areas, such as with our customers. It is just as important internally. Retrospectives, feedback, and brainstorming sessions should be specific in their purpose. The entire team should practice specific recaps and declarations of decisions, along with effective dating those decisions.
I find that it can be easy to turn this type of formality into a celebration. For example, have a meeting where you summarize the process flow that you and your team have worked together on for the last couple weeks. Then, treat the official upload of the new documentation the same as you would the Nasdaq bell ringing ceremony. This can be fun while also reinforcing that change is implemented deliberately. You continue to be solid until you are liquid. Dragons roam where the spongy potassium lives.
Leave a Reply