With all the hype around big data and AI, it is easy to forget why we look at data in the first place.
Hiring the right core team can get you to traction quickly.
How do you feel when you've set up great SOPs and no one follows them? More systems fail due to people not following the processes that already exist, rather than due to failure of the process itself. Like laws.
When you are in an early-stage company or team, your focus will likely be on getting things done than on setting up processes for others to follow. This allows team members to focus on goals and creates a culture with a bias for action. That is a good thing. But as you grow, your team expands and goals become more complex to hit, you decide to set up processes and standards. For instance, as your technology team expands and more people start working on the code base, you feel the need to set up Github with appropriate permissions, establish QA protocols, and commenting standards. If you have a warehouse, you want to set up appropriate documentation and permissions for movement of goods, inventory stock counts, and exception handling.
The processes that worked when you were five people will no longer work when you're fifty. The processes that worked when you were fifty will no longer work when you're five hundred.
As any self-respecting entrepreneur or leader, you set up processes and systems to ensure your business is ready to scale. You tell everyone how to do their jobs and expect full adherence to the new process.
For a week.
Then it is back to the chaos of unstructured implementation. What happened?
This is a common problem among growing companies as well as teams. Here are some things to keep in mind as you push new processes to your employees, that will help you overcome embedded biases in your teams and implement change.
No one likes new protocols and processes shoved down their throat. Depending on the openness of your company culture, employees may or may not tell you that your changes are dumb. Most will likely agree to follow new processes and simply go back to doing their thing. To preempt buy-in from different groups, it is essential to gather feedback from the impacted groups and understand what part of the current processes are failing. Ask them questions, such as: "If you had twenty more developers, would someone be able to understand your code without you sitting down with them?", or "If you're packing fifty products a day for shipment, can you pack a hundred tomorrow?". This helps them understand that their current system needs an overhaul.
Don't fix something that isn't broken.
This process of gathering feedback on existing systems also helps you understand what not to fix. Gathering feedback from the team helps members feel ownership over the final process, and increases the likelihood of embracing the change.
Who should you talk to?
Talk to at least one person from each group being impacted. Talk to developers, new product managers, your packaging guy, the shipment delivery agent, the CTO, the COO.
What should you talk about?
This will probably be unstructured discussions, but focus on touching upon the following:
- What do you like about the current process?
- What tools do you currently use?
- Could this process work if we hired twice as many people? Or if we had five times as much work?
- What metrics are you currently able to track from the current process? What decisions do you make based on those metrics? What metrics are you not able to track?
- What parts of the current process do you think are broken? What would you change about them?
- (For relevant groups) Do you feel like you spend more time doing transactional tasks (e.g., building Excel sheets, copying data, updating dashboards) than what you were hired for?
Creating processes is not about building process flowcharts alone. Using the insights from the previous step, first document the existing process and chalk out the break-points. Segregate these break-points into points that break today, points that will break at 5X the volume, and points that will prevent you from scaling beyond 10X the volume. Involve stakeholders on troubleshooting the break-points and incorporate those changes into the process to build a v1.0.
What can I use to document my processes?
Most often, Powerpoint presentations will meet your every need. They're also easy to share with impacted groups, who can print and post new processes for everyone to review and implement. If your processes are in flux and new processes are likely to change, check out web-based platforms such as Gliffy.com. Gliffy allows you to collaborate on building process maps and provides a host of templates to help you get started.
One change at a time.
Most changes fail because too much change needs to happen in a short period of time. You have a better chance of success by implement one minor change every two weeks than by changing the entire process in one go. For instance, if your process is broken at five points, don't build a new process fixing all five points and try to implement in one go. Implement one fix and let the team get used to it first. Once you feel their behavior is now on auto-pilot, go ahead and implement the next fix. And so on, until the entire process is updated.
Whenever you launch a new product to external customers, you spend a lot of time, effort, and money in communicating the benefits of the product to everyone in your target segment. Yet, when you launch an internal process change, you simply send an email to everyone in the group and ask them to follow the new process moving on.
It is important to overcommunicate internal changes. People often need to be told the same thing five times before the change is internalised. Add reminders through planners, posters on the shop floors, and spot checks to ensure everyone learns about the changes and is on-board with the changes.
Pay special attention to senior leaders who have been used to a certain way, they may find it particularly difficult to change. If they have been receiving a certain piece of data from (say) the Operations team based on the previous process, can the Operations team still pull the same data from the new process? If no, what is the alternative that both the Operations team and senior executives can work with moving on?
After a few weeks of changes, it is time to reinforce the changes with the organization so that they are internalised for good (and you can move on). You know your process change has been successful when it becomes the new way of doing things. There are two important things to focus on at this point:
- Hold employees accountable for the change. Once they have committed to the changes, they must execute on the new processes consistently. If they don't, understand why not and use the feedback to build a continuous improvement loop. If specific employees do not have feedback but avoid following the process anyway, it could just be them being inflexible.
- Celebrate small wins. If your new process helped increase the number of orders shipped per day or reduce the time taken to push code, celebrate the success. And celebrate it with the broader team. When one team realises that adopting new systems and processes helped another team work better, they will be more open to change themselves.
As with all change initiatives, there is no guarantee that the above steps will work. However, if you have not gone through the steps above, your changes are more likely to fail.