Inflexible Process Could Be Stalling Your Projects

Process lets us solve hard problems. Rigidly adhering to outdated processes creates new problems.

Originally published on Medium.com at Inflexible Process Could Be Stalling Your Projects

'Race Day' Image Created by Julie Fleischer Using Canva

Throughout my career, I have bristled when someone referred to me as a “process” person.

It’s not that the label doesn’t, in theory, fit some of what I bring to the table.

If you define process as “a lightweight set of steps or frameworks that help you avoid problems and run faster”, then, yes, I’m most definitely a “process” person.

But the problem is, when someone calls me a “process” person, I don’t know what context they are coming from. And, more often than not, I have found they are operating under a definition of process that means “a rigorous set of boring and potentially lengthy steps that someone said we must follow, which I don’t care to learn and prefer to offload to someone who enjoys ‘that stuff’ so I can focus on solving the cool and actually meaningful problems our team has ahead of us.”

That’s not process.

That is busy-work.

And that is most definitely not what I’m about.

Process Lets Us Solve the Hard Problems

So, why do we as humans or organizations create process anyway?

Process, when done well, frees up our brain so we spend less time thinking about boring things.

When I’m waking up at 5am the morning of a race, I want most of my brainpower going to prepare my mind and body for what’s ahead.

Not figuring out what I should wear or what I should eat.

So, I lay out everything I will need the night before: my clothes, my smartwatch, my water bottle, my breakfast.

And, I feed all those into my checklist (my process) so that I don’t forget any item or any activity before I rush out the door.

It works. I can arise and start thinking about my goals for the run, not where the new bottle of shampoo I bought yesterday is.

This is why software engineering teams have software release checklists. It’s so we don’t forget an activity in the flurry to get the product out the door.

It’s why we have mandatory fields in our change request database. It’s so we don’t overlook both the business and technical implications of a customer request, causing lost time when the deciders attempt to review an incomplete request.

It’s so none of us must spend time thinking about boring things, and it’s so none of us forget important things because we’re so focused on the biggest thing looming at us.

Offloaded Process Reduces Flexibility

The problem comes when we start thinking that process, these steps we’ve created to help us all run faster, can be offloaded to just a few people instead of shared by all.

It would be inconceivable to think I could offload eating my simple carb breakfast on race day to someone else.

Shouldn’t it be equally inconceivable to think offloading the software release checklist management to someone completely unfamiliar with the team is a good idea?

There’s more nuance than that, though.

Someone unfamiliar with a particular team but who, through deep experience, understands well how to release software, bears the battle scars of having been through multiple different release hiccups and is stronger for them, and who can ramp quickly on most any product or team because of their experience, that someone can help greatly. Further, they will be able to give teams guidance and insights from their experience. Having them drive the release checklist management isn’t offloading that piece. That is bringing in an expert to join the team and help.

The problem comes when teams attempt to offload the thinking with the logic that running through a checklist is a simple task that is likely only interesting to someone with limited experience and a small amount of training.

Once you do this, there are a few problems:

- You have created a role that, by virtue of who you assigned and how you trained them, can only ever be a checkbox-checker role. Which, by the way, is a boring role. It is perhaps temporarily fun for someone new and eager to learn and with sufficient imagination to translate the experiences they witness others going through into knowledge they can use in the future, but it’s not a long-term interesting role.

- More than that, you have instituted this inflexible thinking style. Because the checkbox-checker only knows what they have been told, and what they have been told is the checklist has the right answers. Never mind if you re-used your “Summer Race Day” checklist for “Winter Race Day”, and there is absolutely no need for SPF 50 sunscreen on a cloudy, rainy December morning. Never mind if your checklist hasn’t been updated to accommodate for the fact that your customers now value power efficiency much more than performance, but the checklist over-indexes on your performance KPIs as the must-haves.

Lack of Flexibility Leads to More Problems

And, once you institute inflexible thinking, you’ve suddenly created more problems in your organization.

- Now, when a checkbox doesn’t make business or technical sense, it’s not easily fixed by a simple conversation on what does make sense. The checkbox-checker isn’t empowered to change the “Race Day” checklist to make sunscreen conditional on the time of year. They can’t adjust the KPIs to favor more power efficient KPIs without approvals. You’ll have to go through an exception or modulation process, which takes more time.

- More than that, you’ve started sewing the seeds of distrust and misunderstanding. The team resents the extra paperwork to justify something immediately clear to them. Now, process goes from the thing that is supposed to help them run faster to the necessary evil that usually slows them down.

- And, in today’s world, this unnecessary role you created and put someone into also looks like a role that could be offloaded to AI. And, with the right prompts and training, AI can bring reasonable engineering or business judgment to the checkbox-checker role. AI could be better suited to that role than a minimally trained checkbox-checker human with limited experience who will eventually get bored.

But, the AI won’t be able to replace what you needed in the first place: A trained professional who has delivered released multiple products to market and knows what a solid release looks, feels, and behaves like.

So, if you do offload to AI, you will have offloaded the thinking onto something better than you had but less good than you needed.

The Biggest Problem: Inflexibility Creates Distrust

There’s another danger too: Once you have done this enough times, even if you change course, even if you put someone with deep training and experience in charge of your release checklist management, you’ve created distrust and tension in the team that will be hard to undo.

And, once you create distrust, you open the door so that what could have been a meaningful business or technical debate turns into something less expansive, less curious, and more predictable and limited.

People start retreating into their camps.

Statements get said that overlook nuance.

Statements like:

Who cares if we ship on time if we’re delivering a product with bugs? ← Of course, critical bugs are never good for a customer’s experience. Like all of us, I’m a customer of many software products myself, and I have been known to complain, frequently, when a software update adds problems, especially if those problems are significant, like system hangs. But what about the customer that would be willing to accept some manual workarounds in your beta software so that they can start testing the new feature in their environment early? It’s not always this clear-cut what the right answer should be since many business, technical, and environmental factors go into decisions on product releases. However, these statements that start equating moral goodness with one type of decision make moving forward with team cohesion after a decision is made even harder.

But, that’s not Agile. (said when asked to create something like a technical specification or a project plan) ← There is, of course, truth in this statement. If you have a small enough team that communicates well, technical specifications or even project plans may be unnecessary overhead. Unnecessary overhead is definitely not in the spirit of Agile. But, if you have a cross-geography team that needs an easy way to stay connected on key architectural concepts or overall delivery dates, a technical specification or project plan may be exactly what you need to run fast and avoid mistakes. The Agile Manifesto itself clarifies it had no intention of laying out mandates. Just a set of relative values that may adjust based on situation.

That team just doesn’t understand the customer. ← This, too, could be momentarily true. Especially if you are in a company with silos. Some teams may naturally be better connected with the customer. However, saying they “don’t understand the customer” vs. they “aren’t yet educated about the customer’s needs” creates a roadblock instead of an opportunity for education. It also lacks the nuance that, perhaps the other team does understand the customer. Perhaps they are struggling with the balance between multiple customer wants, market pull, engineering effort, and architectural impact and are making tough calls about which direction to move in.

Recognizing the Warning Signs Before It’s Too Late

The solution? It’s not to get rid of process.

Organizations that want to grow need to find ways to offload repetitive thinking so the team has mindshare for the complex, nuanced thinking that growth in this dynamic, fast-paced world requires.

The solution is to recognize that this is what process, when done correctly, will do for a team.

And then resource the definition and management of process appropriately. Set the vision that process’s goal is to improve quality, improve time-to-market, and improve team cohesion. Put those most experienced with those criteria in charge of process definition, continuous improvement, and leadership.

And recognize the signs of slipping into inflexibility: values-based statements about others instead of results-focused statements; lack of nuance on complex topics; a focus on “being right” instead of problem-solving. Then, use these as a wake-up call to re-examine whether the process can flex further to better adapt to a complex reality.

Because process, when done correctly, will help you move fast, solve problems, and feel like one team that can do amazing things for your customers. Isn’t that what it’s all about?