Fear of Process or How to Scale the Team Without Getting “Corporate”

The word “Process”… strikes fear in the hearts of some but can be a huge turn on for others. A single word which became partially synonymous with “Corporate Culture” is our topic for today :)

The world is divided into 4 types of people:

• The junior anti-corporate who is seriously infected with FOP (fear of process) — Just hearing the word will make his stomach hurt and he will do anything to prevent another process and he believes anything effective can be done just by corridor discussions and a whiteboard.
• The experienced anti-corporate who is mildly infected with FOP — while he hates processes, he understands that it is a necessary evil and sometimes a light process is a must to promote and reach certain goals.
• The indifferent — he doesn’t care if there is a process or not. He just wants to work :)
• The process complicator — this one is dangerous! he/she have a strong tendency to complicate the hell out of any process making them way more cumbersome than needed.

In what bucket do I fall? I am an experienced anti-corporate. I worked in a corporate environment for many years and I saw my share of terrible processes but I also saw some awesome processes which made a huge impact on the company. I believe that processes should be as lightweight as possible and should exist only if needed. One of my main goals I set for myself as VP R&D is to grow the team while maintaining the speed of the team and general vibe. I want to take only the positive things which i learned from the corporate mindset and leave the rest out the door.

The other day, our project manager and I set up a discussion with one of the teams to present them a new process we have worked on. The goal of our process is to improve the engineering team impact on the business and product side. A worthy cause, don’t you think? In any case, there was a vibe of resistance to the process in the discussion and it was quickly apparent that more than anything the biggest concern in the room was “do we need yet another process?”. A worthy question as well, which got me thinking… do we need another one, and more specifically, this one?

I came to the conclusion that we didn’t come prepared enough for the discussion, we knew the personas that are going to attend and we could have expected the discussion can easily go to a direction where the focus is on the overhead of the process and not on the value it can provide. So how can we come more prepared for such discussions and how can we effectively target the big question “do we really need this process?” and avoid any such resistance to the discussion. After all, who wouldn’t want to avoid a 2nd or an even 3rd follow up meeting?

There are 3 main questions we need to have a good answer before we can say Yay or Nay on the “big question”:

1. Can we achieve the same goal without a process? or with an even simpler one?
2. Is the process ROI positive? (will it provide more value than it is going to cost?)
3. What is the chance of a successful adoption of the process and why?

So now let’s deep dive into each of these questions, but where should we start? even though you need the answer to be yes on all three questions, you should start with the question that put a big question mark in the process itself as a viable solution. Why you ask? because the other questions might lead to a conclusion that the suggested process is not ROI positive or won’t be a good fit. However, that does not necessarily mean that there isn’t a different process that will actually work.

Can we achieve the same goal without a process or with an even simpler one?

With this question, you should kickoff the entire discussion. You need to align the team so it’s important to explain in depth how things currently work, which areas are prone to failure and the implications if they do. For example, a while ago we implemented a cross-team process of working with Epics in JIRA to manage the development of features that are implemented by more than one team (a single Epic aggregates user stories across several teams to represent a whole feature).

In our case, the way that things worked before was that the product managers were responsible to remember to coordinate cross team features with their fellow product managers but there was no visibility to the project manager, myself (VP R&D) and the VP Product so we could help with cross-team prioritization which is different from team level prioritization. In addition, it was hard for them to manage it because they didn’t have visibility to the stories outside of their team in correlation to the feature they committed to deliver to the customers. Both lead to the fact that things fell between the cracks and commitments were not met.

Ok, so in the above Epic process example we explained how things work, why it is prone to failure (wrong prioritization, easy to forget) and the implications (miss the delivery deadline). Once this is established in the discussion we can go over the possible alternatives and see if they can eliminate the need for a process, or at least minimize it to the bare essentials. Let’s start with the most important one…

Can it be automated? Always consider using automation in order to avoid creating a formal process (seriously, always!). For example, building your product is usually very simple in the beginning but as time goes by it becomes a very complex process if it is not fully automated.

Can the problem be avoided if we reduce integration points? Most problems that lead to new processes are usually related to integration points which tend to break. It’s a fact of life that small teams can more effectively communicate without formal processes but once additional teams are introduced to the equation and there is a need for communication between the different teams, and things start to break more often. Therefore, if you can remove integration points which are not absolutely needed you’ll perhaps be able to avoid the process altogether.

A good example is cross-functional teams. These are teams that by definition have all that is needed to execute inside the core team (dev, QA, UX etc.) and therefore reducing integration points which usually need a formal process to work effectively (e.g. if the QA was external to the team you would have needed a Dev to QA handover process). Another example is avoiding integration in the middle of the sprint. In our group, we first develop completely the APIs on the backend before we start developing it on the client side. This allows us to avoid any need to manage integrations in the middle of the sprint, on the other hand, it does mean we are not optimizing for fast delivery but for process reduction.

Are the ownership and responsibilities clear enough? Sometimes problem occurs because there isn’t a single owner for a task and things fall between the cracks since it is not clear who should do what. Defining clearly who owns what is critical for things to work effectively without many formal processes. A good example is approving a version to be deployed to production. It needs to be clear to everyone who is the single person who should approve it before it goes live. If that is not the case, there isn’t a single person ensuring nothing critical was missed which is error-prone.

Are there any functions which can be removed? Many organization today transfer more and more responsibilities (QA, DevOps, Architecture) to the developers so they will have more autonomy in addition to reducing the need for complex coordination between the different functions.

The more functions we have in the organization the more need we have for coordination. For example, if we have a separate entity of an architect which is external to the teams, we need to make sure that the devs and the architects are in sync on the overall system design and architecture. This can lead to complex design review process, add yet another approver to the chain and reduce the ownership by the developer on the code they develop. Another example is QA, which requires coordination processes like Dev to QA handover in releases and more.

Can a cultural change make a difference? There are companies with specific cultural values which are so strong that they reduce the need to introduce formal processes in the relevant areas. For example, if you have a problem with solving customer issues fast enough or with customer satisfaction, you’ll want to consider introducing “Customer First” as a major value in the company. Introducing new values to the company is a very big challenge and takes time. In addition, it also usually requires starting with some processes at first before it becomes a value which is embedded in the company. However, it is very rewarding and can make a huge impact.

Ok, so you went over the above questions and you realized that you do need a process. However, how do you know if this the most simple process possible? Before moving to the next question on ROI, I suggest you ask yourself the following -

considering the 80/20 rule, what is the maximum I can take out of the process while still getting the main benefit of it?

I suggest you go over each step of the process and ask “is this really mandatory and serves the main purpose? If I’ll take it out or simplify it, will the main goal still be fulfilled?”. An example from my team was the quarterly planning process we worked on, we realized that we can avoid the “quarterly plan review” meeting and just send the slide deck via email instead since the slide deck is pretty much self-explanatory and the meeting didn’t provide much value on top of it.

Is the process ROI positive?

So considering we need a process, and we made sure we simplified it to the bare essentials. Let’s see how we measure the cost of a process and compare it to the value we can get from it.

There are 3 main ingredients to consider when you try to understand the cost:

• Direct cost
• Estimated Indirect cost
• “DNA” cost

Direct costs are easily calculated as they are fixed. For example, if you introduce a process which adds a 1-hour meeting a week for 5 people — the cost is 5 hours per week. Sometimes the additional direct cost that is added is minimal and that’s a good thing because it means that the process didn’t add complexity to the organization, it just made things more defined and clear.

Indirect cost is a different thing, it is hard to calculate because they are far from being fixed and can vary from person to person. Take context switches for example, it is the worst thing you can do to a developer that is “in the zone”, so any meeting with developers will have a negative impact. However, how much impact it does vary from developer to developer. Some can more easily get back into business after a meeting than others.

Another example of indirect cost is the preparation your colleagues need to do before a meeting. Let’s say you schedule a meeting to get feature suggestions on the product quarterly goals which were known in advance to the team. There is no way for you to know how much time each of the participants will invest in thinking about it in advance or brainstorming meetings they will schedule to come prepared.

DNA cost is the most “expensive” of the 3 but it is also the one that is the hardest to measure. Introducing new processes introduces a mental cost and a bureaucracy vibe to the team. It can transform an agile organization to a slow mammoth.

The biggest problem with a process is that it gives less room for common sense

since things are more defined and it is human nature to do the things the same way they are always used to do them. Therefore, in a situation where steps in the process could have been removed and/or changed to provide a better outcome — it might not happen if a formal process is in place.

Now that we did our best to understand the cost, what about the value we can get? In most cases, we estimate the value of a process since we cannot know for sure in what level the process will provide the solution but it is usually easy to come up with a good estimate. Here are few examples of common benefits we get from introducing a new process -

• Quality and stability of the product is the most common one. If things broke and there was a major impact on our customers, we usually can not allow it to happen again. The amount of value we get is in direct correlation to the risk of f***ing up and the impact it will do on our business. So if the risk is high and the impact is high it will be clear to most that the value we can get from the process is very high.
• Efficiency can be improved by adding a process. If things are done inefficiently because of unnecessary steps which are performed or are not performed optimally. Documenting how things should be performed, especially for new team members introduced into the flow, can go a long way. Improved efficiency can be measured by the actual time it saves for the team.
• Visibility is important as you scale the team. Without visibility on key aspects in the project, noise is introduced into the organization in the form of synchronization from managers and stakeholders who want to make sure things they care about are on track. This noise creates frustration and context switches for the team. While it is hard to measure the value, the more noise there is — the more value you get by introducing the process.
• A positive atmosphere and motivation is the key factor if you want to have joyful employees in the company :) some processes provide value by boosting motivation or making the workplace a more fun place to work at. For example, a process that ensures you deliver the product in shorter iterations to the customers will provide the opportunity to celebrate success more often and provide a stronger sense of fulfillment to the team members. Another example is the process we are working to implement these days with the goal of enabling developers to better understand the impact of their work on the business which in turn will boost motivation.
• Introducing new cultural values to the team is a big challenge but goes a long way if you want to make a huge long-lasting impact. In my group at ironSource, we believe that feedback between the team members is crucial so we recently introduced a (very simplified) quarterly feedback process, in addition, the process we have at the end of the year. This was done as part of our goal to embed even further our commitment to feedback and constant improvement.

Last but not least to consider when thinking about the potential value of a process, is considering the short term vs the long-term value you’ll get. It will set the right expectations on which fruits you’ll get to enjoy when, so you’ll avoid disappointment. Obviously, it is easier for most to relate to short-term values so it sometimes better to focus on that depending on the personas in the discussion.

What is the chance of a successful adoption of the process and why?

So we are at the last question, which can throw everything out the window even if the answers on the 2 previous questions were a clear cut YES. So how do we go about it? First, you should ask yourself -

is the process a good fit with the company culture or the maturity of the company?

For example, introducing a yearly performance evaluation processes in a company where the core value is ongoing feedback, might not be effective and can reduce the on-going feedback given by managers because they have a point in time they can “aggregate” feedback for. Another example is a strict and complex design review process in a small startup which values agility and fast delivery.

To increase confidence and also learn from others mistakes along the way, it can be beneficial to check if there was a successful adoption of a similar process in similar companies. If so, try to reach out to them and ask for insights.

Lastly, do you expect any resistance from those infected with FOP? If so, what is the expected impact of this resistance and how are you going to mitigate it? To answer this, I suggest you follow these steps -

• Name the key individuals critical for the process to be successful
• Conclude if they are more likely to be in favor or against the process
• If you believe they will be against it, what do you think will be the reason? Can you get them on board? If so, how will you do it?
• If you want to be extra careful, make sure they pass “the talk in the corridor” test. Try to raise the topic informally in a chit chat and see how they respond.
• Move forward only when you feel you can get them on board!

Wrap up

So, do you need yet another process?

Finding the sweet spot in the organization where you utilize exactly the right amount of processes is practically impossible. Sometimes you’ll use a process that provides less value than what it cost and sometimes the opposite. It means that you need to remember the 3 questions -

1. Can we achieve the same goal without a process? or with an even simpler one?
2. Is the process ROI positive?
3. What is the chance of a successful adoption of the process and why?

and consider them for each new process but you’ll also need to ask the first 2 questions on exciting processes every now and then to make sure it stands the test of time.

I wish you a successful journey scaling the team without getting “corporate”!

p.s. If you understand Hebrew, check out this interview where I discuss this subject in depth מפתחים חסרי תרבות — פרק 45