The Goldilocks of Process

One of the most confusing moments of my young professional life was when a co-worker taught me how to send a fax to email. At the time I was still on Wall Street, and faxing client paperwork was (and probably still is) commonplace.

The steps were as follows: take out the original document, make a copy of it, fax the copy, and put both the copy and the original back into the client file.

While I do enjoy making copies of paper, I had to ask: “Why make a copy? Why fax the copy and not the original? Why save the copy afterwards?”

My co-worker told me this is just the way it’s done. She learned it this way, and it works — so why question it?

A while later, I discovered that the process of creating a copy and adding it to the client file was a holdover from before fax-to-email services existed. At the time, you needed to make a copy of every fax for auditing purposes. When fax-to-email services were implemented, the fax-to-email system was able to save all incoming and outgoing correspondence, eliminating the need to make a copy. And yet, the process stayed, because it was part of someone’s job.

The process mentality

An example from the product management world happened to me recently. The team I was working with needed to update the Terms and Conditions on their website. Typically, this requires the legal team to edit an existing file with new language. In our case, they had edited the file, but someone had forgotten to update the revision date. Catching this, we simply updated the date on the website and pushed the change to our QA environment.

Then a bug report surfaced, which outlined the discrepancy between the date in the file (attached to a Jira ticket), and the date on the website itself. After explaining the error and how we corrected it, the client’s product manager insisted we change the date on the website to reflect the erroneous one in the legal file, “because we cannot make adjustments to what legal sends us.”

Blindly following process is a project-killer — not just in terms of efficiency (though both of these examples are inefficient). The real poison here is the mentality: in these cases process became a crutch to lean on, with these individuals no longer thinking critically about their tasks. In many ways, the process became the job, where process really should be what enables the job. This rings doubly true in the software development world.

On any team, you want your process like you want your porridge: just right. If you have too little, the team may not know what the priorities are, or who is responsible for the next step. Too much, and your team will end up doing more process than actual work — which is what happened to me. The right strategy should be flexible enough to fill in the cracks of the team’s blind spots while enhancing their strengths. It’s up to the PM to find that sweet spot.

Direct juniors without hamstringing seniors

This is tricky, because a team usually consists of folks across a spectrum of skills and experience. The more senior the team overall, the less granular the process requirements. Additional layers of process are more useful to junior team members, as long as they don’t use process as a means to stop using their brains.

The PM needs to understand how their decisions around team process affect their own responsibilities as an individual contributor. When the team is more junior, the PM should take a direct role in defining the process. This can be quite granular and may include choosing tools, setting up workflows, creating documentation, and assigning tasks. A hands-on approach also benefits the junior team members, as they get clear direction on exactly what they should be doing, and a methodology for carrying out their tasks. Importantly, these extra layers also allow for easier course correction if things do get off track, as the PM is more able to pinpoint where things went awry.

With senior teams, the PM should look to take a more supportive role in defining the process. Experienced team members tend to have established ways of completing their tasks, so the PM should incorporate the most relevant of these methods into a cohesive plan. This involves meeting with each team member and learning about their processes, then making decisions about how those processes apply to the project. The big challenge here is building consensus among the team about what to keep.

If the PM and the team are at approximately the same level, you have an opportunity to collaborate on the processes. As with anything that runs right down the middle, this will need to be a combination of cherry-picking relevant established processes, and then working together to create others where gaps exist. Buy-in is most critical here, as the group is navigating through uncharted waters and following new workflows.

What to watch out for

The PM has to avoid a few pitfalls to set themselves up for success. The first and most obvious is that no one follows the process that was laid out and agreed upon. The silver lining here is that this is a very easy thing to fix. After you get initial consensus from the team, the PM can document the process and socialize it. This makes enforcing the process much easier, since it’s something everyone has already seen.

The other pitfall is what I have been discussing. It can be very tempting for your team members to view following the processes as the job itself. The best way around this is for the PM to keep a watchful eye on the team’s tasks, and adjust as the landscape changes, throwing out processes that don’t work and adding where there are gaps.

At the end of the day, the entire team should view process as a means to help everyone execute work more efficiently and with greater transparency. Just remember, it’s not a silver bullet and that issues are going to come up. And hopefully your process framework is such that those issues are easy to pinpoint and resolve.

Phil Johnson is a Lead Product Manager at Postlight. Drop him a note: philip.johnson@postlight.com.