Formal and Informal Processes
3 min read
Processes are just codified ways of doing something. An agreed upon set of steps that people use to turn resources (inputs) into value (output).
A lot of people think of processes as being rigid and cumbersome. This can be true, especially in things like manufacturing, where controlling quality and consistency is very important. You can't have a person on an automotive manufacturing line, YOLOing how the brakes are assembled.
Processes exist on a spectrum. Some are highly prescriptive while others are loose guidelines or best practices. More importantly, there are two distinct classes of processes, formal and informal.
Formal
Formal processes have two important conditions.
They are documented
They are enforceable
Inside a company, a formal process will be well documented and (most likely) have training associated with it. More importantly, it will have consequences of it is not followed. Formal policies like HR policies or security polices can have significant implications for not following them (e.g. termination, legal liability).
Informal
Informal policies look very similar to formal process but the big difference is that they are unenforceable. In companies with a lot of informal processes you will hear "this is how it's done here". In the absence of documented processes, people will create generally accepted ways of getting things done that become embedded in the culture and institutional memory.
With the rise in apps like Notion or internal wikis, it is very easy for people to create informal processes that LOOK like formal processes. This software and some basic, well designed, templates create very official looking documentation that sits alongside formal processes. It is difficult to tell the difference between a formal and informal process inside these systems.
While an informal process can be documented and taught (just like a formal one) it can not be enforced. The big tell on if a process is formal or informal is if there are consequences for not following it.
As it relates to Design, there are rarely enforceable Design processes in most companies. Designers will create informal processes masquerading as formal ones and be disappointed when they are not followed.
More broadly, Silicon Valley has an allergic reaction to formal processes when it comes to software. It prefers to keep things fast and loose. This means that informal processes crop up to fill the gap. The problem with informal processes is that they are often hidden or passed down through word of mouth. Like a game of telephone they get broken along the way. It also creates unreliable dependencies between teams. Each team running its own informal process makes collaboration very difficult.
Coda
Everything written here about processes is also true of policies. Inside an enterprise there are formal and informal policies. Teams will create things that look like policies but they lack any teeth because they are unenforceable.
Designers will create Design Principles. Privacy teams will create checklists or best practices. These are only as valuable as their enforcement.