How to Maintain a Startup Mentality

Problem

As an organization grows, new processes are being added. People simply need to track, connect, communicate, or audit, and as a result, organizational processes will evolve. Suddenly, everything has to become documented and approved, which erodes the agility that is driving most startups forward. Most people join startups because they enjoy working in a fast-paced environment with agile processes dictating the workflow. As you can imagine, they are not happy about losing their agility, flexibility, and speed to deliver value to their customers.

The problem is that too much administration is being introduced at some point, while empowerment following those same processes is being removed. That starts to slow things down, and once that takes over, it is hard to change it to the previous state because the administration has a tendency to place its roots deep and wide. Therefore, before introducing any new process, one should reflect on why and if it is needed and what is the added value of any new process.

Actions taken

Whenever I would have to introduce any new process, I would ask myself what the goal is or why we are introducing it. I use value-stream mapping, also known as material- and information-flow mapping, to understand if the new process would add value or introduce waste. It allows me to see how much time it would take to arrive from the start to endpoint while visualizing the new process. Frequently, the challenge is not in why we are doing it but if we could do that differently. We would need new processes, and by analyzing data, we could spot their weaknesses and the opportunities they carry along. Moreover, the analysis would allow me to assess if we would still be agile enough after introducing them. If we would be sacrificing some agility, would it be compensated by the value which would be added?

Or in some cases, we would have to question the existing processes given the changing nature of a rapidly growing startup. For example, people would be filing Jira (or any other tracking tool) tickets and then would be perplexed by the existence of some fields. Why do they need to fill those? Those ceased to be relevant a long time ago. This is when we should take a more backward approach to see whether the purpose those processes served would still be relevant today. If not, it just slows things down and should be discarded.

Also, when we set up a new process, people tend to build for the unknown. People project everything that could go wrong or what they might need, building something that is too large for the organization. My experience is that when you are in a growing startup, you should build processes for two times the size you are today. That would create enough room to mature without being stuck but would be still lean enough and adjusted to the size of the organization. That projection would not be large and over-engineered to impede the existing processes. Therefore you should carefully study your growth: the number of people and the number of projects. You are building processes for your next step, not for your CEO’s ultimate dream.

Furthermore, we should understand what purpose new processes serve. Is it to track or to communicate, for example, and what do you expect as a result? I often see in larger organizations that communication happens through work items, which is not the most effective approach. In the past, people would pick up a phone or set up a Zoom meeting, and things would be settled through that one call. Later, people would instead file a ticket and communicate through that ticket rather than picking up the phone. Jira was introduced for tracking, not communication, and introducing a tracking system doesn’t mean that you have to change your communication habits. Every process should have its distinct purpose: it shouldn’t change or replace all other processes by default.

Lessons learned

• Track value a new process brings. Every process has its ROI, and you should be able to measure it. Oftentimes, processes in scaling organizations are introduced for audits. Things need to be certified and controllable. Indeed, audits and certifications are all about control, but control can be exercised through various mechanisms. Try to keep them close to the people who are working with them.
• Don’t over-engineer. When you build things, you build them for your size and a slightly bigger size. Engineers get carried away easily, especially when they need to impress their superiors.
• Know who is working with which processes and who will be impacted by the change. From a management perspective, things often look easy, “Just create this ticket; it’s five minutes of work.” But with a ticket here and a ticket there, a developer will be spending 50 minutes filing tickets and not developing. What do you think a developer prefers to do -- code or do the admin work?
• Provide the context. People are willing to do some admin work if they can see some value in it. If they don’t understand why they have to fill in a ticket, they will most likely avoid doing it or complain at least. Sending an email announcing that a new ticketing system will be introduced that can do A or B is not enough.