How to Make a Process People Won’t Mind, Without Losing Yours
Photo by David Travis on Unsplash
What’s one overlooked factor that will make your organization more likely to succeed? I believe it isn’t something flashy, like a more charismatic leader or a new, more exciting product. Instead, the hidden x-factor is process — all the little things you do regularly and systematically that form the operating system of your company. For example, there are too many areas to list all the places processes can help, but a few are product launch & engineering sprints, customer service queues, sales lead generation, partner on-boarding, compliance, payroll, hiring, on-boarding, compensation and performance management.
I like to think about processes as products for your organization/team.
Someone recently asked me about engineering team processes, and I realized process is so overlooked that even though I’ve worked on it my whole career, I haven’t really written about it. So I’m starting a series on process, and in a future post I’ll share some “greatest hits” that have worked well for me.
First, though, let’s discuss designing useful processes. I like to think about processes as products for your organization/team. Sometimes the process will be paired with a more literal product (e.g. an internal tool), and other times it will live on its own as a set of guidelines. For example, you may have a content development process that depends on an internal CRM, so that process changes mean the CRM also needs to change. Hiring, meanwhile, might be a written protocol, and daily sprints may have unwritten guidelines. Regardless, the purpose should be making people’s lives easier — both your’s and your coworkers’.
Start With Research
Processes have two characteristics that lend themselves to research. First, they likely won’t be 100% unique — while they’ll need adapting for your organization, chances are someone somewhere else has also faced the same challenge. Second, they have users who can provide valuable insight into what works best for them.
I like to start broad by looking at external research and seeing what people at other companies have already done. This can take many forms. It can be as simple as a google search for similar processes, or a search of a website like First Round Review. If you know other people who’ve faced the challenge, it could also be asking them to chat. Similarly if others at your company have worked on similar challenges, they can be great sources of knowledge.
The purpose should be making people’s lives easier — both your’s and your coworkers’.
After getting a sense of what’s out there, I like to narrow possibilities by doing internal user research. Interview the people who’ll be using your process to find out what matters to them. If there are too many people to interview, you can also use a survey. Some questions to ask are, in relation to the new process:
What areas are most important to you?
What pain points do you have that you’d like to alleviate?
What one feature would make this most valuable to you?
What are you most afraid of?
What shouldn’t we do?
If you’ve done research and identified some pieces from other processes that could work for your organization, you can also ask people about these during your user research. For example, “I’m thinking about organizing our product board this way, as it seems like it worked well for other organizations. What do you think about trying that here?” or “I did some research and saw that there are two main ways other companies seem to standardize their marketing emails. Do you have a preference?”
Note that people may disagree as to what is required, and you may have one person saying something is most important to them (e.g. a weekly meeting), while another says that is something you absolutely shouldn’t do. That’s ok as you’re just gathering data for the next step, testing your hypothesis.
Testing Your MVP
Instead of rolling out a large process with many steps, try starting with a test of your minimum viable process. This should include any pieces the process must have for it to work. The reasons for testing are: 1) to test your hypothesis as to what’s required and see if the process works as intended and 2) to resolve internal disagreements as to what is required.
As you design a test, make sure your test runs for a manageable time period. If the process will be used daily or weekly, then keep the test to a few days or weeks. If the process will be less frequent, you’ll need to get more creative. If you’re testing an audit process, you could try running a small pre-audit to make sure the process works before the stakes are real. No-stakes trials are also great for performance review processes — you can either do a test prior to your first formal review cycle, or you can use the first cycle as your test cycle.
When you roll out a test process, communication is key. Write down the steps to be followed during the test, and let people know that you’ll be following up after to get their feedback.
Emphasize that this isn’t permanent and that you will iterate after receiving feedback. In my experience, people are much more willing to try something new when it isn’t framed as something permanent. For example, if someone is afraid that changing the team meeting format will mean they don’t get the information they need, you can ask them to try it for a few weeks and then revisit.
In my experience, people are much more willing to try something new when it isn’t framed as something permanent.
While the most important pieces to test are those you believe are required, if you uncovered some “nice to have” pieces during your research you can also test these. Here testing is most important if a) there’s disagreement about a “nice to have” — i.e. some people want it and some people don’t or b) you aren’t sure if you want to include that piece and want to gather data about how it works.
Note, though, that while it’s good to test some “nice to haves” if you can, you should also keep your first test simple. There are two reasons for this. First, the process will likely need to change after you test it in practice. If you spend too long fine-tuning each detail before you test, you may waste both your time and your collaborators time. Second, the test period also functions as a way to get people comfortable with the new process. Rolling out your new process as a 10-page, single-spaced document makes it more likely that you’ll turn people off to the whole process, creating internal resistance and keeping you from getting the test data and buy-in you need.
Gathering Feedback
After testing, make sure you gather feedback. As with initial research, user interviews are invaluable. I also like surveys here, as they allow you to get results in a format that you can easily share with everyone who’ll be affected by the process (as long as you’re upfront that results may be shared). Here you can ask about how the test worked and whether the person’s answers to the first round of questions are still the same. For example, you might ask (using a scale or agree/disagree when appropriate):
How easy was the new process to use? What features made it easy, and which could be improved?
Did the test improve your work life? If yes, how? If no, why not?
Did the test process make you more productive? If not, where did it impair your productivity?
What did you most like/dislike about the new process?
Did the test process solve your pain points? If not, what would it need to include to solve them?
Does the process address the most important issues for you? If not, what would address them?
Are there additional features the process needs before it will be useful for you?
If you identified an area you were most afraid of, do you still have that fear? If so, what would the process need to allay that fear?
Is there anything else you’d like to share?
For features where people were opposed before the test (e.g. half thought the meeting should be Monday and half Friday), you can ask everyone what they prefer after the test. I’ve found these questions helpful even though you likely won’t get everyone to agree. Asking the question shows that you value each person’s opinion, and seeing how other people responded and their reasons why provides transparency into your decision. Again, though, if you’re asking this type of question make sure to be upfront that you may share these results with others. Also consider allowing people to respond anonymously, or to only share the results after you’ve anonymized them.
Asking the question shows that you value each person’s opinion, and seeing how other people responded and their reasons why provides transparency into your decision.
After you gather feedback, you can incorporate changes and then run another short test, and keep iterating on these tests as necessary. You’re more likely to need additional short tests for processes that are complex and happen frequently (e.g. a process for reporting bugs or getting through a customer service queue), processes with very high stakes (e.g, audits) and processes that involve software products such as internal tools. For other processes, one test may be all you need before you’re ready to “launch.”
Launching the Process
To me, a process is ready for “launch” when, if it’s used daily/weekly, you’re ready to commit to it for a few months. If it’s quarterly or less, then launch would be the first cycle where the results are “real” (e.g. an actual audit or a performance review cycle).
As before, communication is key. When you launch the process, make sure that you’re clear with everyone about why you’re implementing it. Remember that the process should be serving you/your team/your org, and articulate how it achieves the goal of making peoples’ lives easier.
Similarly, make sure everyone knows there will still be opportunities to provide feedback and iterate. Launch does not mean the process is fixed for all time. No matter how much you test, issues will still come up after you launch the first version. Let everyone know that you still want to receive feedback and that you’ll run another survey after X time period (or X cycle). Then, make sure you follow-through on that survey so that you don’t burn trust.
Launch does not mean the process is fixed for all time.
Your process should be a living document. It probably won’t ever be 100% perfect for all time because the company’s needs will change, peoples’ priorities will change, and new team members will join who weren’t part of the initial discussions. This is especially true if you’re growing quickly, as a process that works well for 8 people likely won’t work the same for 100. So keep gathering feedback and iterating.
Documentation
When you launch the process, you’ll want to make sure it’s documented clearly and kept up to date. Documentation should include both the what of the process (i.e. the steps) and the why behind the process. When testing for clarity, I like to ask if a new hire could pick up the document and be able to both run the process and understand why the process exists. As the process creator, you can also ask, if you left the company tomorrow, would anyone be able to pick up the process and keep it running? Both of these questions will help you balance comprehensiveness with simplicity.
Closing Thoughts — Rewarding Process Design
Even though good processes can be the difference between winning a market and losing to a competitor, it’s often hard to convince people to spend time on processes. Often, people are responding to implicit or explicit signals about what your company values. So if you want people to develop strong processes, you’ll need to make that part of your culture.
There are several ways to make strong processes part of your culture. If you set company goals/OKRs, you can be an exception and include ones about different processes. If you’ve defined company values or you’re working on them, you can include one that speaks to the importance of good processes. And, perhaps most importantly, people tend to value work that is recognized. When someone takes the time to create a new process, praise their work the same way you would if a team launched a new product. By recognizing and incentivizing process success, you can make useful processes part of your company’s DNA.
If you tried any of these suggestions, please let me know — leave a comment or email me at TLTCoaches@gmail.com.