In a well-oiled organization, every team member should be dealing with processes on a daily basis. It’s not just an issue for managers. Everybody, from top to bottom, should be able to contribute to how processes are organized.
Processes, workflows, procedures, SOPs—they’re like algorithms in code. The difference is that these algorithms are used by people, not machines.
Even small teams have processes, although they might not think of them that way. Any time you say “this is how we do things on our team”, you’re already talking about a process.
Process management is important, but processes have a bad reputation
Any standardized way of completing a repeatable task is a process. But people often don’t think about it this way.
Procedures are often seen as a rigid, corporate-only approach to work. If you have to work with standardized processes, you’re just a tiny cog in the big machine and you can’t use creativity in your daily work, right? The truth is a bit different.
A well-designed, properly managed set of standardized workflows actually enables your team to be more creative, and add more value in their daily work. Another great thing is that processes enable teams to exchange best practices. By default, you want your process to encapsulate the most efficient A-to-Z steps to finish tasks, like building a feature, fixing a bug, or recruiting new people.
People in your team will need to discuss how to do their tasks, share their ideas and methods that work for them. That brainstorm leads to finding the most efficient way to accomplish a task.
And that’s what processes are all about: finding the best way to do something and making it easy to replicate.
Two essential reasons for introducing processes
There are two organizational aspects that create the need for processes – complexity and automation.
Work, especially in tech companies, is getting more complex. If you can figure out the best way to do a repeatable task, and organize it in a simple workflow, this frees up time to focus on other tasks.
For example, when you have a detailed process for building new features, your team can get to work quickly by following steps—they don’t need to re-think how to add a new feature every time.
This doesn’t mean creating a conveyor-belt type of workplace—tech companies aren’t factories. Modern work is complex, especially cognitive work. In tech, pretty much all you do are complex cognitive tasks. The mental burden is high, and reducing it is crucial to improve productivity and avoid burnout. That’s what processes are for. They reduce the mental burden in everyday work.
The other big need for processes comes from automation. You can automate a lot of your repeatable daily (weekly, monthly, yearly) tasks, but you need to define them in detail to enable automation.
First you need to define the input: a new feature is built and needs to be tested.
Next, what needs to be done, step-by-step: extensive tests are run on the feature, and the code gets refactored.
Finally, the intended output: a new feature that can go to the client / project manager to be evaluated.
Defining the input, necessary steps and output is exactly what you do when you design a process. By reducing complexity and automating tasks, everybody on your team can be much more productive. To achieve this, you first need to prove to your team why processes are important.
How to build an organizational culture that accepts processes
You don’t want to run a dictatorship in which you define the process, because tech companies don’t thrive in such conditions. As a manager or CEO, you wouldn’t be able to work out, and continuously improve, all of your company’s processes in an environment like this.
In order to be accepted by the team and to stick in the long-term, processes need to be adaptive. There needs to be a built-in mechanism for improving them over time. That mechanism is a feedback loop.
The feedback loop doesn’t just happen. It evolves from an organizational culture that’s built around feedback and cooperation.
From day one on the team, people need to know that they can influence their workflows, that their processes aren’t set in stone, and that if they have feedback, it will be heard and considered.
As a manager, you should encourage people to think creatively about processes that they’re involved in. If they think that change is necessary, they should be able to voice their opinion, and you need to hear them out.
Don’t direct people to internal wikis or documents. Give them time, explain the company as a living organism and show where the process fits in, and how other people depend on it.
Imagine this: one of the developers comes to you with a suggestion to improve the QA process. What do you do? A simple mental simulation is a great way to address this.
Discuss how the change would play out. Ask directed questions – how would this specifically affect other team members? What would need to change, and how much would it cost? What about edge cases: would the new process hold up?
Your team will see that you care about their opinion, and that their suggestions will always be considered. If you want a tight-knit team, people need to see that you’re all about teamwork, not shut-up-and-do-as-I-say-work.
Another hugely useful habit here is providing positive feedback as soon as people deliver value, make a good decision, or complete a process quickly and efficiently. As humans, sometimes we get so caught up in focusing on mistakes that we forget to appreciate accomplishments.
To create a thriving culture of feedback, you should always give positive feedback whenever good things happen and achievements are made. That’s not all – you need to also include that positive feedback in regular growth review meetings. Show your team that you care about their contributions.
The difference between helpful processes and rigid bureaucracy
How do you know if processes are still helping your team, and not making their work harder than it should be? It’s easy to create so many procedures that people get lost, or even paralyzed. But it can be avoided as long as you maintain a continuous improvement mindset. Feedback needs to be an integral part of your culture.
When your culture is based on continuous improvement and feedback, then your team becomes the very mechanism that will prevent processes from becoming too rigid.
Whenever a process adds complexity instead of reducing it, people will stop, rethink things, and suggest changes. If processes are like algorithms, then this is like refactoring your organizational code.
A designer would say that perfection is not when there’s nothing left to add, but when there’s nothing left to remove. This rule works perfectly for process management.
Which tasks are most worth turning into processes?
Most tasks that are repeatable can be enclosed in a process. If you do it regularly, you might want to think of making a process for it.
Another indicator of a task that can be enclosed in a process, is when multiple people have to cooperate in doing something – especially if they don’t work together on a daily basis.
Some examples are below.
• Recruitment and onboarding
Where are the best places to look for candidates? What are the best ways to test their skills? How do you find out whether they fit into your team? Once you hire someone, how do you make them feel at home as fast as possible?
With a great onboarding process, you can get a new team member ready to add value within a week. Without any onboarding process, it can take months until someone is at full capacity.
• Giving someone a promotion or pay raise
It involves a manager / team leader, an HR person, someone who does finance, and sometimes legal (in case of contract changes). A perfect opportunity to ensure smooth cooperation between departments with a solid process.
• Incident handling
When there’s a security incident, it requires cooperation between the person who found it, the incident manager, an admin / secops person, top management, lawyers, sometimes customer support, and PR.
• Offboarding after finishing a project
A good offboarding process will make sure that you always collect feedback from key stakeholders and close the project in a way that there are no loose ends.
• Quality assurance
This is a perfect area for creating processes. Without any processes, it will always take a lot of discussion—how it should be done, at which stages, should it take place at team level (if multiple teams work on a product), or at a higher level, and so on.
• People evaluation and team growth management
People evaluation is an interesting case because this area calls for a relatively loose, adjustable process. You don’t want to measure everyone’s growth the same way. People are different, which is why it is important to approach evaluations with an element of flexibility, rather than rigidness.
Your process should consist of basic steps for talent management—like regular meetings, goal-setting and reviews, the approach for each team member during these steps should be individually tailored.
Within the realm of software development, release planning and crafting product roadmaps are just two examples of activities where a codified process could pay off nicely.
We could name more examples, but the bottom line is that more likely than not, there are people in your organization right now who are performing tasks that should be turned into more formalized processes, to the benefit of all.
How do you marry the Agile manifesto with process management?
We all want to be as Agile as possible, and the Agile manifesto is the gold standard to look up to. At first glance, the manifesto seems to argue against processes. One of the points states: “we value individuals and interactions over processes and tools.” Did the authors of the manifesto mean that you should avoid processes?
Not at all. There’s no contradiction between the Agile manifesto and process management. The manifesto doesn’t say anything about NOT valuing processes and tools—it only tells you that people are more important than processes.
Developers and tech managers know this well. For example, your development team might have set up automated deployment of code to the production environment. That’s the process that works. But when developers need to deploy something manually, they should be able to do it too.
Whenever there’s a situation that requires a unique approach, the process can be changed, or omitted. Common sense should always be able to trump the process.
Processes are meant to be improved on, changed, and made to fit your team. Even when you consider a standard like Scrum, every Scrum team uses their own version of it. The fundamental laws of Scrum are in there, but it always needs to be adapted to your unique context.
Tailoring processes to your team’s needs is nothing extraordinary, it’s the most natural approach
Complexity is the best metric for deciding when to organize a process, because it can mean different things. If you’re adding people to your team at a rapid pace, complexity goes up. If your team isn’t growing, but your product is becoming bigger and you’re adding a lot of new features, complexity goes up too.
As soon as complexity starts growing, the need for standardized processes arises. It’s better to start organizing processes too early, than to start organizing them because you’re having incidents like production faults, security breaches, data leaks, or employees leaving due to frustration.
Whenever complexity goes up, processes can help you reduce it.
What to remember
In any work environment, processes are all around us, whether we standardize them or not. When you get around to organizing your work in processes, there are a few key rules to remember:
- Common sense should always trump processes: when the process is actually making your work harder—rethink it, or get rid of it.
- Processes are always subject to change: you should keep improving processes not just as a manager, but as any member of an organization.
- Everybody in your organization should know that they can suggest changes to processes: you need a culture of continuous improvement and feedback.
At the end of the day, it’s about guiding actions, and not dictating them.
Marcin Zabawa, Head of Service Delivery, STX Next