Beyond Agile (7/52): How to build great processes
One of the many important functions you will perform as a TPM is process development. Here is some practical advise and thoughts on how to create effective processes.
All Processes do two things:
1️⃣ Slow things down.
2️⃣ Speed things up.
Treat every PROCESS as a SYSTEM.
All systems have inputs, outputs, and processing. A system also has fundamental truths that can’t be broken.
If your process relies on teams to provide a high number of inputs, engineers will see it as a nuisance and it will fail.
If your output’s signal to noise ratio is too noisy, no one will pay attention to it and it will fail.
If processing inputs takes a long time, teams will not see its relevance and it will fail.
Here are my true, tried, and tested strategies on how to build effective processes:
Reduce the number of inputs required from teams. If you can’t reduce them, then front load them for the teams.
Spend time and care into the visual design of the output. You have few seconds to grab peoples attention, if they cannot figure out how the information is laid out. Don’t bury the lede and everything doesn’t have to be powerpoint slide.
Regularly collect feedback on the process and if it is achieving the original intent. If feedback is bad, make modifications, deploy revised process, monitor, collected feedback, iterate.
Build in affordance to when the process should be ignored if the situation called for it. You should have a fast track path with value creation must always coming before process.
If your process requires additional energy with each iteration, it will fail. Examine the process to find what’s not working, find the leaks, adjust, try again, iterate.
Why Purposefully Build Processes to SLOW DOWN Teams?
For large cross functional projects with numerous moving parts and many teams, slowing things down prevents unexpected totally preventable disasters.
Google has a process in place for all big Android projects particularly open source ones. LaunchCal is how we made sure to prevent obvious mistakes.
Each organization had a launch readiness checklist template with key stakeholders signing off before the project ships. You could not ship until all sign offs were complete and it was the TPMs job to make sure the sign offs happened.
For our Android Things project, we reviewed a number of critical tasks including but not limited to:
Security Review (source code review with Android Things Security team to prevent any security holes or issues).
Legal and Privacy Review (make sure our changes do not require additional legal reviews particularly when working with vendor IP, data collection and accounts).
Test Reports and QA team sign off (make sure we are not shipping a broken release).
Product Management sign off (making sure we are shipping what we intended).
Final the SVP of Android And Chrome Platform (the final buck stops here).
What may seem like necessary to others, to us it is the difference between rolling a major release after launch and potentially bricking devices or celebrate a successful launch of new features to our customers.
Ultimately, whatever process you create, you must monitor its efficacy to the original goal, collect feedback, make adjustments, iterate. Above all, know when to be dogmatic, when to be flexible on adhering to process, and when it is time to retire the process entirely.
Until next time 👋!
-Aadil
Feedback on this week’s newsletter: