Posted on by & filed under being awesome, leadership.

What do you think of Process (with a capital “P”)? Are you someone who loves it and thinks it’s the end-all-be-all that will make everything better? Or are you someone who hates it and thinks it just gets in the way of you doing your job?

While the latter is more likely, if you answered “yes” to either of these questions then you’re thinking about it all wrong.  The problem is that you’re thinking of processes in terms of Process and not in terms of People.

When I graduated from college, my first job was on a team that was bringing process and tool changes to an Ops organization.

I dove right in and learned about the industry-wide best practices and tools that the organization wanted to use.  I heard that what we were doing wasn’t working and that we needed to change.  I spent a lot of time implementing the system, talking to consultants, creating tools, giving talks, presenting to management, etc.

From a business perspective, the project was a big success.  We moved to the new tools and processes and it worked.  I even earned the title of “Process Guru”.

I was proud of my success, but I felt incredibly stressed.  While the project was successful from a business perspective, it was less than stellar from a people perspective.  I was so sure that the new processes and tools were better, that I didn’t spend nearly enough time understanding the impact of the changes and working with the people affected to make sure the tools worked for them.

For example, one comment I heard several times was, “We’ve been doing it this way for ten years. We know what we’re doing.” At the time, I had two reactions:

  1. If you’ve been doing things the same way for ten years in this industry, then you must be wrong since the world has drastically changed.
  2. If your way is working, why is the business demanding change?

The thoughts I should have had related to this statement were:

  • The change I am proposing will have a dramatic impact on your life, and I need to understand how.
  • You’ve had a lot of experiences and learnings that are valuable.  Help me understand them.
  • You have not yet acknowledged that there is a problem that needs to be solved.  Let’s work together to align on the need.
  • I need to find a way to convert you to being a champion for the idea.

The ultimate measure of success of a good process is that you are able to turn someone from a doubter into a champion.  It’s a tough challenge, but it’s a lot easier if you go about it the right way.

 

 

Why we create processes

Before we get started, it’s important to understand why we build processes in the first place.  It’s usually the result of some failure, and we build a process to make sure we don’t make the same mistake again.  It’s a worthwhile goal, but it often leads to processes that address only a single problem.

When you add up a ton of processes addressing single problems, people get overwhelmed.  A better approach is to look at the whole system. If there was a failure, it’s often a sign of a bigger problem.

For example, I once led a team that was faced with an overwhelming support load.  One approach to addressing this problem would have been to partner with our support team to get better at handling escalations.  We did that, but if we had stopped there then we would have been back in the same place in less than a year.  Our short-term metrics would have looked good, but we wouldn’t have solved the larger problem.

Instead, we looked at the big picture and asked: Why are we having so many escalations? How can we improve quality? How can we prioritize real problems?  How can we get insight into what our customers are experiencing?

Once we understood the bigger picture, we made a number of improvements that made things better for our customers (by improving quality), for our support team (by empowering them and helping them be heard), and for our engineers (by reducing cognitive load and focusing on meaningful problems).

Another reason we create processes is to address some external need, such as tracking time for budgeting, getting approvals for expenditures, making sure we’re complying with regulations, etc.

Unfortunately, these rules are rarely created with people in mind.  As a leader, it’s your job to play by the rules but also consider how to do so without making your team miserable. Often this means building simple-to-use tools that meet the need without burdening people with awful processes and user experiences.

Finally, processes get created to make a team’s or person’s job easier. While this is a great reason, it can often lead to really bad processes because they’re optimized for a single individual.

For example, you might build a process that makes sure that someone signs off before a software deployment. This might involve someone entering tons of information into a form somewhere, which would make it easy for that individual to have all the information they need to make a decision. However, it might mean that someone else has to spend lots of time fighting with a bad tool.

So why do we fail so often when we try to build processes? The following approaches are designed to help you succeed more often:

  • How to keep sight of the problem you are trying to solve
  • How to win people over
  • How to build usable processes
  • How to measure whether a process is working and adapt it if it’s not
  • How to know a good process from a bad one

 

How to keep sight of the problem you are trying to solve

Your first job is to make sure you really understand the need, which may not be clearly defined.  Even if it’s clearly defined, it might be defined in terms of a solution to the problem rather than a clear problem statement.  For example, a poor problem statement would be, “We need to make sure that people sign off before we release updates to our product.”

A better, problem-focused statement would be, “We keep forgetting to notify our Sales department when we release big new features in our product.” This leaves room to innovate on the solution and allows you to validate that your solution solves the right problem.

Guide conversations about the problem towards what is working and what isn’t working.  Really listen, try to understand, and dig below the surface. Talk to both the person who identified the need and to others involved in the situation.

This step is absolutely critical. You might design a process that may solve problems, but they may not be the problems you are actually having.  This is also the first step in winning people over to the process you are designing.  We will get to that more in the next section, but you need to take every opportunity to get people aligned with the problem and the solution.

Once you have a clear problem defined, write it down and refer to it frequently to make sure you still don’t end up solving the wrong problem.

When I set out to build processes, the first thing I do is look to see how others have solved similar problems. I like to read books and learn from experienced people. But be careful. The way others have solved problems may apply only loosely to your situation.  Blindly applying someone else’s solution can make you lose sight of the specifics of your situation.  As you’re learning and talking to people, keep the problem statement with you at all times.  Every time you iterate on the process, make sure you refer to the problem statement and stay focused on what matters.

 

How to win people over

You may do a great job creating a process that solves your organization’s problems.  However, unless you get others behind the process, it is doomed to fail.  “Others” refers to all stakeholders, from your sponsor through every individual involved.  You’re not seeking everyone’s approval, but you need to at least understand their concerns.

As mentioned above, the first step to winning someone over is to make sure they’re aligned with the problem you are trying to solve.  Several years ago, I tried to make some changes to how our organization delivered software.  My approach basically went like this:

  • I saw a problem -> I proposed some process changes at a management meeting -> No one was engaged -> My proposal died

I didn’t realize it at the time, but there was no way this approach was going to succeed. First, I didn’t spend the time getting others to identify with the problem. Second, I proposed a solution without working with others.

In hindsight, I would have done better if I had:

  • Engaged with people right from the beginning, when the problem was observed
  • Worked with people on defining the problem statement and the process.
  • Gotten people to self-identify with the problem
  • Gotten buy-in prior to presenting the process to a broader group

You need to make a conscious effort to win people over.  It doesn’t come for free and it’s one of the most important things you can do to successfully create and implement processes.

 

How to build usable processes

People are the most important part of good processes, and that doesn’t just mean the people who benefit from the processes. Don’t forget the participants who will implement the process.  If you make life hard for them, your process could fail in subtle ways. For example, people might:

  • Bypass the process
  • Do the minimal amount of work needed to support the process
  • Talk negatively about the process and feel that there’s too much bureaucracy

So how do you win over participants?  You focus on making the process usable and give them tools to make it easier.

Sometimes even the best possible process results in more work for individuals.  If your company is moving from a small startup to a public company, for example, there will likely be more work for people who support financial processes. Take budgeting, which becomes much more important in a larger company, burdening people who aren’t experts with difficult to use tools and processes.

So what should you do?  Treat it like a software usability problem with the goal of making it easy to learn and use your product.  The way you build usable software is to study and observe people who may or may not be new to the software.  Do the same with processes and tools.

Go sit with the people using them. See what kinds of problems they encounter. Measure their frustration. Really bad processes will result in lots of sighs, visible signs of frustration, cursing, and even pounding on a keyboard. Do you think I’m exaggerating?  I have witnessed all of these before, and it’s painful to watch. You do not want to be the cause of such pain.

You can avoid much of this by observing the users of your process and tweaking it to make it easier for them. For example, when my team addressed support concerns, part of our solution required entering additional information into our ticketing system, which added steps to the process that were prone to error.

After watching several people on the team make mistakes entering data, we spent half a day building a  browser plugin that took several steps out of the process and reduced a lot of mistakes. It also reinforced that we cared about the impact that the changes had on people, which helps build support for the entire process.

 

How to measure whether a process is working and adapt it if it’s not

A beautiful process on paper might not work at all in the real world.  So how do you know if it’s working?  You measure it. Remember how I said to keep referring to the problem statement?  That applies after you implement a process, too. Follow up and make sure you’re getting the results you expected and you’re solving the problem you set out to solve.

How you measure the process depends on the problem statement. If you create a process to reduce support load, you need to make sure the number of support calls you receive actually goes down.

If  your process isn’t working, you may need to tweak or discard it.  Don’t get locked into the process just because it makes sense to you. Be honest with yourself and make sure that the process actually has a measurable impact.  Try to recognize when something isn’t working as early as possible and change it if necessary.

Also, just because a process worked when you created it doesn’t mean that it will continue to work. The world changes and you must adapt your processes along the way. Don’t forget to check in frequently and measure whether it’s still working. You might also create new problems when you solve old ones, so stay vigilant.

 

How to know a good process from a bad one

Beyond measuring whether the processes are working, however, there are some even simpler, more human questions you should ask yourself:

  • Is the process you created reducing friction for people?
  • Is the process making people’s lives easier?
  • Are you adhering to a process for process’s sake or because it is useful?

If there’s one thing to remember, it’s that there are actual humans involved in any process you create. Pay attention to their needs and you’ll have a much higher chance of success.

If you have any questions, thoughts, or experiences you’d like to share, please leave a comment below.  I would love to hear about and discuss your experiences with bringing these kinds of changes to your organization.

 

Kirby Frugia is an Engineering Manager at New Relic.  He likes to build and nurture highly motivated teams that deliver meaningful products by creating an environment that sets people up to succeed.

You can connect with him on LinkedIn or on Twitter @kfrugia.

Tags: better leader, change, process, productivity, Strategy, success, team,

Comments are closed.