Process is a Product for Teams
I know, the title seems controversial — People don’t generally like Process. Some would say, if we want to move fast, we need fewer processes — so that we can move freely without “restriction”.
However, they may be confusing “busy” with “making progress”. If you watch these cooking shows, you often see amateur chef cooking — he moves very fast, works a lot, but gets very little done. In contrast, a master chef moves with grace, not frantic but gets a lot done — because she has a great cooking process that plans ahead, makes fewer mistakes, reduces back and forth runs, and enables more parallel tasks, e.g. baking main course while prepping for desert.
Process is a Product with a goal for Performance. Continuous process improvement leads to higher performance.
Think about it for a second: Process is a product — it’s used by people to solve a problem or address a need. Typically we build a process to standardize best practices learned in our successes and failures doing the similar things, e.g. building software, onboarding new hire, etc.
A process allows future work to be more effective as we don’t have to reinvent the wheel every time and suffer from preventable mistakes.
Using Process as guiding principles
Because process aims to reuse best practices, it’s almost always evolving, which makes it important to document both the steps and goals behind them.
This reminds me those training chopsticks. They have harnesses to restrict your fingers on how to use them. Once you learn it, you may vary the way you hold chopsticks depending on the needs in different situations, or different pairs.
Same is true in adopting and applying processes in your work — taking process as what it is intended be (the guiding principle).
Understand Your Process: Always start with the Why
How do you decide which part of process to follow and which not? The key factor is to understand the reason behind the process. What’s the problem it tries to solve.
In a recent blog post “Antidote of Bureaucracy is good judgement”, AirBnB VP of Engineering Mike Curtis called out ““replacing policy with principles”. I’d add another ingredient to this — communicating the rationale behind process whenever we establish a new process, or make changes to existing ones. When doubts come up during a project or within team interaction on whether we need to follow certain process, we may need to do a refresher on the Why’s of a process.
Minimum Viable Process Rollout
We all know the perils of waterfall — giant vision, lots of brainstorming and design, tons of changes, and then release a product with fingers crossed. This approach has been proven to frequently fail to achieve the giant vision set out in the first place.
Designing and rolling out a new process is no different from designing and rolling out a new product. Do user interviews to understand the problem. Choose a beta group to test out the new process, based on feedback tweak it. Then do a soft launch — that is, apply your process to the intended group that it is a “beta period” and feedback is encouraged, tweaks may apply.
One key element of the process roll out — is to always attach it to a tool. The tool is part of your process product. Imaging you release a mobile app, on powerpoint mocks to every user? So having the beta process in the chosen tool helps you to design, implement, and tweak your process product in the final form it is adopted.
Treat Process Debt Like Tech Debt
Processes are frequently updated, often with added use cases when problems occurred. Overtime these processes tend to become more “comprehensive”, but steps for 20% of the use cases may not apply to 80% of other use cases. Often the environment for which the initial process was built has evolved such that a good part of the process has become obsolete.Interestingly if you look at old, not properly pruned code base, you tend to see many “if” arguments lead to various corner cases. For your Process Product — you need to manage your Process Debt the same way you manage your Tech Debt. You need to decide whether to remove unused / obsolete processes, or re-write part or most of it in a new perspective based on the latest business practices. Key factors include team structure, collaboration maturity, types of work, etc.
A few year back when I first joined Bigcommerce, a 300 people ecommerce platform startup, we built an Integrated Product Delivery Framework (our version of PDLC), quarterly product planning ,following the Responsive Portfolio Management process. It was built when we were establishing a brand new R&D office in San Francisco. So there were many guard rails to keep the team stick to the process. After 6 months of adoption by the global cross functional teams, our planning, tracking, collaboration and communication tools and process had been adopted really well across the board. We started to look for opportunities to lighten up and eliminate the “scaffolds”, i.e. enforcers, put in place initially to hold the new process in place. After pilot tested it with a few project teams, we rolled out our PDLC 2.0 with a lighter weight, more flexible process adjustable based on project size/ complexity/ risk levels. This greatly helped to further improve the time to market and allow project and product managers to do more with the same headcount.
Originally published at scaffoldcorp.wordpress.com on June 25, 2015.
