A series of actions that you take in order to achieve a result. - Cambridge Dictionary
A process is ubiquitous in our day-to-day job. We use processes everywhere:
When describing how we ship a parcel to our customer.
How you need to request vacations.
How a new item is added to the backlog.
How the performance review is conducted.
Processes provide clarity on how to achieve a result. A process isn’t bad per se, and yet we find ourselves in processes that prevent us from being efficient enough, leading toward a “bureaucratic organization.”
I have been part of several startups. I loved startups because they were processless. You know what you need to do, and you move forward. But, somehow, in all of them, you start to feel in the direction of a bureaucratic organization after some time.
I will share the different types of processes, how and when you create them, and how to reasonably avoid being trapped with non-value add processes.
What does a process provide us?
Processes have very appealing properties:
Improves efficiency.
Provides clarity on how to reach an outcome.
Moves the responsibility from the people to the “process itself” (or ultimately to the people that designed the process).
Yet, it has some drawbacks:
They are a simplification in a complex environment.
They are static or not adaptable enough in a continuously changing world. A process that worked yesterday might not work today.
Adding a process is a very natural thing to do. Just imagine the next scenarios.
A process that makes sense
A person in the organization wants to take vacations. They are the first to ask for it, as we are in a startup and things are fast-moving, and we never did it before. They talk to the CEO and ask for vacations.
Jules: Sure! Let me know the dates.
Alex: 3rd of April to the 10th of April. Recall that the 10th is a national holiday in Spain!
Jules: Done! Please, add it to your calendar as Out of Office to let your colleagues know you won’t be available during those days.
Then, Jules opens a Google Sheet, creates a new row, and marks that Alex will be out from the 3rd of April to the 14th of April, which means that Alex requested 9 vacations days as the 10th is a national holiday in Spain, which means that Alex has 16 days remaining.
Of course, this doesn’t scale! Let’s add an HR tool to track the vacations, and we ask people to add the vacations there.
🔖 Process added. Asking for vacations
People and culture deparment:
HR setups the tool (only once)
When we onboard a new person, we add them into our HR tool (once per employee)
Employees:
Ask for vacations via our HR tool.
Your direct manager needs to approve the vacations.
Not bad. Makes sense this process.
✅ Leads to efficiency as now it reduces the work for all parties (manager, people department, and employee).
✅ People know how to ask for vacations autonomously.
✅ The process is clear and makes sure each party does their job.
Another example:
Developers: When a new customer signs up in our fintech application, do we need to verify anything from them?
PO: Yes, we need to run a Know Your Customer (KYC) process due to legal requirements. We need to verify their identity when they sign up.🔖 Process added. KYC process
We validate the email and phone number
We require a picture of their Identity Card
We validate the card using X provider
We require a picture of their face with a certain hand position that we determine previously so that we can be certain that it is taken in that precise moment.
✅ Leads to efficiency as the KYC process is well-known and can be automated.
✅ People know how to implement the KYC process in-app.
A process that might not make sense
Startups go fast, and, for whatever reason, the CTO has been deploying the solution manually (pretend this still happens instead of using templates that come with CI/CD out of the box).
The company grows, and a new developer needs to deploy into production.
Developer: We need to deploy this new feature. How do we do it?
CTO: Sure, let me share with you the process to deploy into production.… some bash scripts, ssh connections, AWS console changes manually, some manual docker builds later…
CTO: Done!
Developer: Let me capture this as a document.🔖 Process added. Deploy to production scripts and step-by-step manual
In this example, we added a process that might become the company's standard to deploy into production. The process is not challenged; therefore, the Developer Experience doesn’t have space to improve.
A process is blocking the developer team from continuously improving their delivery process.
Another example. The development team starts to grow, developers start building features, and we find that we are not aligned late on the delivery process.
PM/PO: Why are we doing this feature? Did we align with our stakeholders before starting?
(Someone did something that they shouldn’t suppose to do, we add a process to prevent it to happen again).
🔖 Process added. Product delivery process
PM/PO:
Manages backlog
Set priorities
Define Definition of Done
Developers:
Assigns themselves into tasks
Reports blockers there
Asks for QA when the feature is ready to be released
Here we can see how a process added bureaucracy to the organization. After some months, this will become “That’s how this is done in the company,” it will be harder and harder to improve the development processes.
They all are processes, but they mean different things in their contexts
We have seen different types of processes:
Operations Process: How to ask for vacations
Business Process: KYC
Infrastructure Process: Deploy to production
Team Process: Backlog management
and more.
We can sense that processes by themselves aren’t a good or a bad thing. They depend on the context we add them and how much rigidness they add to the organization.
Why do we end up in a bureaucratic environment, then?
One of the key mistakes we all make is to add a process to solve people's problems.
As the company grows, we have accumulated human mistakes that we aim to prevent by adding new processes.
The process can be desirable for multiple people in different positions:
Management: I want to avoid this mistake from happening again.
Team members: I don’t want to make this mistake again. Tell me how to do it.
In both cases, we move the responsibility from the people to the process. Ultimately, if you follow a process, you are doing your job.
A process that aims to solve a people’s issue won’t be able to capture all the complexities of a fast-changing environment that requires high adaptativeness from everyone in an organization has been added.
A process that addresses a people problem will mitigate the issue in the short term but cause more in the mid-long term.
After some time and several processes like this later, you find yourself in a very tight environment that suddenly looks bureaucratic.
The root cause of ending up in a bureaucratic environment is the false expectation that you can fix your people's problems with processes.
Which is the alternative?
The journey won’t be pleasant as you must acknowledge that mistakes are essential for an organization to learn continuously.
People are the biggest asset, and creating an environment to help people to thrive is essential for long-term success.
When mistakes are made, your reaction is critical regardless of your role.
Do you consider a mistake something that brings problems to the person that caused it, or does it bring learning to the organization? Depending on your answer, you will become a bureaucratic or high-performing organization.
When some mistake is made at the human level, I like to remind myself of this Norm Kerth quote:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
From there, I ask myself the next questions:
In which context did this situation happen?
What led people to do what they did?
When we answer those questions, we can understand the people's context and then assess if we can solve the situation with:
Organization principle. A guiding principle for a certain situation where people can assess if the principle applies to their context and, if not, apply their sense or align the expectations.
Sharing context about which is the desired outcome. Often, when we share our desired outcome, people will adopt their habits and methods to fit it without needing a detailed step-by-step process.
Adding a process.
Meme for you
