The No Process Process — 6 Tips for Reducing Process Overhead and Increasing Developer Independence, Velocity & Innovation

As (engineering) managers, we sometimes tend to believe that our role is to “create order in the chaos” and that the best way to achieve it is by bringing in a clear set of standards, rules & processes.

While a good process / standard can have a positive impact on clarity and order, when excessively used, it can kill innovation and even hinder velocity & motivation.

Process is a bit like a salt, when used sparingly, it will spice up your dish, balance it and accent other unique flavors, but when excessively used, it will override all other flavors, pickle and ruin your dish all together.

To clarify: by “Process” or “Standard” I mean any set of rules on how to perform a specific task, so that we don’t only dictate what to do, but how it should be done (e.g., coding standards, design guidelines, protocols for delivery to production, production incident management processes etc.)

So, How can we balance standards & processes with developer independence?

In other words, how can we have the cake and eat it (with our pinch of salt :)

Below are 6 tips that can help you create this balance:

1. Build standards bottom up

Standards are there to resolve some kind of pain. Developers are typically the ones feeling the pain — therefore they should be the ones building the solution.

Create an ad hoc team of developers, to map the issue and suggest a solution or a standard.

This will also allow the standard to be tailor-made for the developers, and make them much more engaged, rather than trying to apply a new rule / process top-down while detached from the problem at hand.

2. The need for standard / process needs to be well reasoned, documented and communicated

You should have a very good explanation of the motivation (i.e., pain the standard comes to resolve), and how it introduces less overhead and negative impact than without it.

Document the explanation so it’s referable to future generations.

This explanation also needs to be defined bottom-up, and should be clearly communicated and discussed when applying it across the organization.

By “discussed” I mean actually discussed (rather than preached). You need to be willing to hear feedback, pushback and challenges to verify it will actually achieve the expected ROI. And be willing to drop it, when strong, genuine & justified pushback arises.

Note that applying a new standard is a change to the status quo that was applied thus far.

Developers (as most human beings) don’t like change, and therefore a default reaction to change may be pushback, so you need to listen carefully and impartially to the pushback in order to distinguish between auto-pushback (the natural reaction to any change) and a genuine one.

3. Don’t fall in love with your process — be ready to kill it or change it when needed

Standards are there to fulfill a purpose. The purpose is not to fulfill the standards.

You need to remember this, keep reviewing the standards on an ongoing basis, verify that it stands the test of time and still fulfills the original purpose. And if not, be able to change and adjust, and sometimes completely eliminate it.

Standards tend to become a habit, and habits may turn into cargo cult, where people just follow the standard without knowing or questioning what it’s there for and without checking if it actually archives the purpose.

Or even worse, if people don’t understand or agree with the purpose and don’t feel comfortable to voice their opinion, they may try to workaround the standard. They might end up either ignoring it or blindly ticking the box missing the original intent and thus creating meaningless red-tape & frustration.

A few techniques you can use to keep standards to the test and avoid this slippery slope:

1. Set reminders in your calendar, for 3/6/12 months since the standard/ process was introduced, to check its efficiency. It can be a check you do on your own, with some team representatives or with all engineers.
   I try to include it in a periodical survey to all engineering teams gathering feedback on efficiency of all our main standards and ways of working.
2. Create an open and trustful culture where people are encouraged to give sincere feedback and voice their opinion when they feel something doesn’t work or doesn’t make sense (best way to achieve it is by actually listening to feedback, acting upon it and communicating back the actions based on the feedback. This is how people will know they are heard and can make an impact, and therefore, are also accountable for things not changing if they don’t voice their feedback)
3. Do just that :) communicate back the aggregated feedback, and the actions you’ve taken based on it. If a process failed, communicate and celebrate it’s extermination. If the feedback is positive, celebrate the process continuation based on it’s continual efficiency. In any case, be transparent and celebrate :)

4. Minimal (to none) enforcement

If we envision a spectrum of enforcement levels — varying between no enforcement whatsoever, to full enforcement (with ramifications of failing the enforcement), you would want the vast majority of your standards to not be enforced.

In general, you should favor facilitation over enforcement.
Invest your time in making the standard as accessible, well known, understood, and easy to use, rather than in chasing everyone to follow it or penalizing teams that don’t.

Roughly speaking, I try to have the following split of our standards

• 40% no enforcement whatsoever
• 10% enforced
• 50% somewhere in between

Let’s drill down a bit to understand best practices and examples (we apply at Wix) for each

1. Enforced — these are the business critical standards, where not following the rule may have a significant and immediate negative business impact (e.g., regularity requirement, cost related guidance). In these cases, we have to enforce adherence to the standard. (examples where we do apply enforcement: GDPR and PII adherence, wasteful resource utilization)
2. No enforcement whatsoever — these are the cases where we fully trust the team’s judgment to apply (or not apply) the standards that fit them. In these cases we still need to provide guidance, training, documentation on best practices for the standard, making the documentation accessible and discoverable to all, but not enforcing adoption of the standard.
   An example where we do not apply any enforcement is design guidelines. At Wix, we created comprehensive guidelines and documentation of design tradeoffs and recommendations (based on our collective lessons learned from designing large scale, performant and resilient systems). We also created design templates and provided intense training on both.
   But each team decides whether and how to do their design, and whether to use the guidelines.
   Each team is entitled to make their own design “mistakes” or discoveries, and update the overall guideline if they find any new design lesson learned.
   Teams are also encouraged to request a design review if they feel it is beneficial for them.
   The overhead of enforcing design guidelines (e.g., having architects review & approve designs) would have created bottlenecks and frustration, kill exploration and innovation, and not have been worth the ROI.
3. Somewhere in between — these are the places where not adhering to the standard would create an impact (important but not a critical one) and we trust the team’s engagement in fulfilling it without the need to apply further enforcement. In this case, in addition to standards & guidelines, we also need to provide communication on the motivation, importance and expected timeline (where applicable) and expect teams to provide visibility on when and if they will adhere.
   An example for such a standard are the dev languages and platforms we support( e.g., in Wix for backend engineering, we decided to provide support for Scala and Node.JS only). A team that wishes to develop in a different language can do so, after they’ve consulted with the guild, explained their unique needs (and why they feel it can’t be supported with the given frameworks) and confirmed they understand the overhead they’re taking on themselves (which is to support the Wix infra on their own including multi DC deployment, CI, CD, failover and reliability) and still expect to have a positive ROI.
   This is how we can make educated decisions on exceptions to the standard, and also get a good sensing on whether the standard needs to be changed or extended (e.g. if we’ll see an increasing number of justified requests to use a new language, we may decide to expand our standard and framework support to it as well).

5. Automation Automation Automation

Did I mention automation? Since we want the process and standard to work for us, rather than us working for the process — the best way to achieve it is by taking away the overhead of the process as much as possible and automate anything that can be automated.

A few examples for standard automation we’ve built in Wix:

1. We expect teams to conduct post mortems including measuring the impact the incident has on production. To avoid a big manual overhead, we’ve automated filling the impact by linking incidents to business KPIs and automatically collecting the impact at the time of the incident (from opened till resolved).
2. We’ve built a system called “CI buddy” that provides visibility to any team on their code adherence to any rule. In some cases, the system also provides an auto PR allowing to automatically fix the code and adhere to the rule.
3. Since compliance to regulatory requirements (via PII encryption, getting and deleting PI information) is a cross company / service concern, we’ve incorporated support for it in our platform and frameworks. Developers get it out of the box, do not need to remember it or reinvent the wheel each and every time they build a new solution.

6. Always Allow Exception to the rule

Even if we apply rules, process and enforcement, we always need to make sure we allow exceptions to the rule to allow for innovation and self-check.

Here are 3 examples of where you’d want to make sure you have rule free playgrounds:

1. Hackathons — where the innovation aspect is critical and easily killed when applying processes.
2. POCs — where we’re looking to prove added value or fail fast we can not afford (and shouldn’t invest) in adherence to standards if it comes with a significant overhead. Once and if the POC is successful, productizing the offering will need to adhere back to the standards.
3. Where the process / standard does not solve the problem it was originated for. (see my example of Wix backend supported languages standard above)

Have your cake and eat it (Too)

So, in order to reach the balance between process and developer independence, we, as managers, need to focus our efforts on: deciding which standards are actually needed, forming & revisiting them collectively and continually, and facilitating their automation & ease of adherence as much as possible.

By doing this, we significantly increase our chances to achieve what we aimed to achieve in the first place: velocity & motivation without hindering developer independence.

Have questions? want to share your thoughts and experience on engineering culture? feel free to reach out via linkedin