Organizations Live and Die by Process

Steward Those Processes in Service to the Goals and Values

One of my morning aspirational habits is reading. This morning’s book, The Innovative Team frames the FourSight framework. I wrote about , and mentioned that framework.

Organizations that actively reflect on their process:

  • Tend to be more open to novelty because they are striving for innovation, not only end results and deadlines
  • Deal with conflict promptly because they see problems as they come up rather than being blindsided by them later on
  • May have less conflict between employees because they appreciate the diversity and strengths each person brings to the table
, The Innovative Team

The Innovative Team starts with a business parable; I skipped it and jumped to the later chapters that provide some concrete observations and approaches for the four phases of problem solving: clarification, ideation, development, and implementation.

I shared the above list with my partner; she owns Soapy Gnome. She and her team reflect on their process, and regularly tweak and adjust. And Soapy Gnome manifests those three bullet points.

Then I think to other organizations that I know that seemingly don’t reflect on their process. I’d imagine the unbearability of the situation at those organizations.

I’d imagine process adjustment recommendations would be met with hostility. I’d imagine lots of subtle political campaigning via narrow and limited communication channels. And situations simmer and bubble for months, providing ample opportunity for each person to begin telling their own story of the events.

, I reflected on my use of the Atom text editor 🔍. I found it lacking and began exploring other tools. As a software developer, Visual Studio Code (VS Code 🔍) could have be a natural fit. I adjusted my process to give it a try.

And I found one function to be unacceptable: writing a commit message for Git 🔍. There are two paths I would take when writing commit messages. First, I would run git commit on the command line, and through the $GIT_EDITOR environment variable, the command would launch my text editor with a buffer for writing my commit message. The second method was using my editor’s built in git integration.

It was this built in git integration that sent me looking elsewhere for an editor. At the time, when I used that method VS Code would provide a text input to write the commit message. That text input was about the size of an address line field; in other words it encouraged very short commit messages (about 30 to 50 characters).

And I find small commit messages to be antithetical to creating good processes around software developer. For example, this past week, one of my tasks was working on a refactor of Samvera's 🔍 Hyrax code base. This first involved reviewing the given issue, doing some screen share discussion with the tech lead, and then beginning to code towards that proposal.

I wrote the following commit message:

In discussion with @noreply, in addressing #4195, we want to explore the following path:

  1. As early as possible in the request cycle, create a Hyrax::UploadedFile for both a CarrierWave file or a file selected for upload by BrowseEverything.
  2. Building on step 1, we would then hope to reduce branching logic in the request cycle, and preserve existing class interfaces.

By making this non-breaking change, I’m orienting the code to deliver on this aspirational goal.

Next steps would be:

  1. Update the Hyrax::WorksControllerBehavior to create Hyrax::UploadedFile records for the files selected from BrowseEverything (note CarrierWave handles the “inline” uploads).
  2. Adjust the extracted Hyrax::UploadedFile#perform_ingest_later method to handle files that were created from BrowseEverything.

The plan is to add a field to the UploadedFile (perhaps url_of_file_to_ingest) that the Hyrax::WorksControllerBehavior would populate based on user input parameters.

With that in place, we could look at backporting the solution into the ActorStack.

The purpose of the commit message was to capture the conversation between @noreply and myself and provide clues on the next steps. I submitted that commit as a draft pull request and sought confirmation from @noreply that this was their envisioned direction. The code change itself was minor, but provided enough of a hint at the likely next steps.

I also wanted to write those notes, because I didn’t know when I’d next get back to that work. So the commit was also a breadcrumb for future me (or some other future contributor).

Had I used the input box of VS Code for writing the commit message, I don’t think I would’ve had the patience to write that commit message. Which, had I not reflected on my process, I might have chosen VS Code for my text editor, and began making choices that might undermine my decisions. For those curious, I use Emacs 🔍 and the amazing Magit package.

Now imagine if an organization didn’t reflect on their use of tools. Had they mandated everyone use VS Code for writing git commit messages. The byproduct of that decision would likely be more terse code commit messages. Which would be hindering one communication channel for software development; and certainly increasing the cognitive load of reflecting on the historical changes of your code base.

Now think about those small decisions throughout the various organizational processes. Calendars with default meeting times set to one hour. The periodicity of a sprint relative to the cadence of work outside of that sprint scope. Numerous communication channels paired with numerous people each whom favor one channel over another.

Organizations are sloppy, and as much as I’m a “process” guy, I’m far more concerned with the people. So let’s summarize the original bullet points from The Innovative Team and rephrase those as aspirations and where we create conditions where:

  • We explore novel approaches
  • We address problems near to the time when they arise
  • We embrace, accept, and elevate people’s knowledge, skills, and abilities

And one of the methods for doing that is to actively reflect on the process. This is why the sprint retrospective is powerful; you look at the recent events and identify what worked, where you got stuck, and what you might change. You also demonstrate a shared ownership of the process; in which each person is stewarding the effectiveness of that process.

Or, in other words, build your shared aspirational values and goals, then sketch out processes that can deliver on that. And continue working those sketches as you move forward together.