Process Without Shame

What do you think of when you think about process? Is it nimble, innovative, and productive, or slow, inefficient, and expensive?

Here at Postlight, and often in the larger technology community, the word is almost a taboo. People tend to celebrate process when it streamlines hardware production, such as Henry Ford’s assembly line or the obscenely efficient factories that churn out iPhone after iPhone, but in software we’re convinced it slows us down. We’re too smart for these checklists, surely!

To be fair, we’ve all been in day-long sprint planning, backlog grooming, and and endless kickoff meetings that leave no room for actually getting work done. Strict adherence to process, in the wrong hands, is miserable for everyone.

Personally, I love process. I find it makes me a better product manager and a more thorough strategist. But when you work with people who have already been burned, you need to take extra care.

To put it bluntly: people, not process, are the problem.

This post isn’t about how to fix your process. (I’m sorry, I know that’s probably what you wanted.) Instead, let’s talk about how to make the rules of process-oriented management work for everyone.

Focus on problems, not process

Unless you only work with PMs (a very specific kind of PM, really), your colleagues do not want to hear you gush about process. They don’t care about the Trello system you designed, or the JIRA swimlanes that will make your life easier. They care about getting their work done.

Recently, one client of ours wanted to implement daily synchronous 30-minute full-team check-ins. On an 8-person team, that 30 minutes turns into 4 full staff hours of work that wasn’t getting done each day. In this case, the request for “more process” was getting in the way of the real issue, which was an anxious client. Having diagnosed the problem we needed to solve, we adjusted course and instead conducted daily asynchronous stand-ups over Slack, and a semi-weekly synchronous client-PM check in. We got more time to improve the product, served the needs of the client, and made everyone’s day a little more manageable.

Treat implementing process on your team the same way you treat implementing a new feature in your product. Focus on the problem — why it exists, where it came from, and how you can solve it. Definitely think about the unintended consequences of any solution. Treat your colleagues like the users you’re normally designing products for, and offer as much respect and empathy as possible. How much extra time or work are you going to ask them to give with your new system, and how much value does that create? The latter thing should be bigger than the former.

Measure twice, implement once

One of the biggest fears that people have about process is that something new is going to disrupt their work, only to be replaced by yet another rule or technique. So, make sure you’ve found the right solution before you introduce it.

If you have friends on the team who are willing to help you experiment, use them wherever possible. One trick we often use at Postlight is to have an extra Trello board/Github project board/Slack channel just to test things out amongst ourselves before introducing it to larger teams. Test out your ideas just like you would beta test a new feature with your most trusted users.

Then, when it’s time to introduce a new workflow, give plenty of context for the change. Your team members need to know you’re not upsetting the apple cart without a reason.

Avoid rigidity — change isn’t bad!

Perhaps the thing people are most frustrated by is the nagging of a PM who insists that things be done a certain way for the sake of the process. If you’re that person, I have this to say to you: I’m sorry, but you are wrong. The only reason you should be adamant something be done a certain way is for the sake of your product and your users.

In our recent work with the Knight Foundation — a very short and ambitious project — we added, changed, and removed various collaboration techniques a number of times. What we needed in the design phase was not what we needed in the engineering phase, and the copy required its own unique system. Each method served its specific purpose, and lasted no longer than absolutely necessary.

Stay on the lookout for ways that your systems are getting in the way and slowing things down, and for areas that could benefit from a change.