February 13, 2024

Here, do whatever you want, as long as I approve everything

IMG_1060

A little bit of process will set you free, but too much will crush you.

Too little process risks creating chaos, but too much of it slows everything down.

How do you strike the balance?

Here are five questions to help you do so. Before implementing your next organizational process, ask your team this.

Will this process create autonomy that boosts speed, or enable dependency that slows us down?

In any workflow, if there are unnecessary layers of approval at every step, then that’s too much process.

The goal should be to minimize thrash and reduce the total time through the feedback loop. Otherwise you end up with single person bottlenecking the project just because they’re not available to sync up in real time to be the final set of eyes on everything.

I used to work with the founder quite a bit at my startup job, and he was the worst offender of this process inefficiency. It was great that he liked being involved in the public relation function, and his insight led to several quality press mentions.

But there was no need to have a seven person email thread, multiple text message chains and a fifteen minute meeting to compose a four sentence quotation.

Leaders need to actually trust their teams and empower them to maintain speed with whatever path forward results in shipped work.

Maybe that means being involved for five minutes at the very beginning of the project and then buggering off. Maybe that means asking if leadership input is necessary at all. Whatever the balance is, it’s in service of optimal throughput.

Will this process require an investment in infrastructure that’s expensive and takes time and energy away from creating value?

I once worked at an ad agency that decided to start requiring employees to complete time sheets for their clients. People had to use this new software platform to calculate exactly how much of their day was spent on which account.

The task took at least an hour a week per employee, if not more. The work was tedious, frustrating and notoriously difficult to calculate. Because sometimes people were doing work for multiple clients at the same time. Or doing work for their own benefits outside of typical account responsibilities.

What’s more, our managers didn’t even meaningfully use that data. It’s not like they unlocked all these efficiencies and suddenly got better at resourcing the team. They just got busier and angrier. The time tracking data outpaced our ability to analyze it.

And after two months, it was clear that the juice wasn’t worth squeeze. Eventually, we stopped all the tracking madness and refocused on doing work that created value for our clients.

Does this process eliminate multiple downstream problems, or create more of them?

Immature teams will often immediately react to every hiccup they experience by immediately adding a process. But they don’t realize, with every new process, the risk is introducing unnecessary points of friction that compound quickly.

Sometimes new processes are implemented to eliminate downstream tasks, but end up creating more work for everyone.

I used to have a boss who was vigilant about over processing our team. I’ve never worked at an agency that so few meetings, and it was wonderful. Jose would always warn us:

Before you call an all team meeting, please multiply the number of attendees by a hundred dollars an hour. That’s what we charge our clients. If there are twenty people in the room, and we spend a half hour together, then your idea needs to be worth a thousand dollars.

In this case, he created this forcing function to question processes before they were adopted. Each team, therefore, should figure out the minimum change they could make to realize benefits.

Because maybe we don’t need to have yet another weekly call to waste six people’s time brainstorming. Maybe a simple survey on the company chat platform would suffice. What we’re looking for here is the smallest increment of process that would add value with the least amount of friction.

Will this new process empower and simplify, or control and overcomplicate?

It’s astonishing how often leaders create processes that pay lip service to freedom, but in actuality do the opposite. Read any company’s career page, and you’re likely to see core values like autonomy, flexibly, freedom and ownership.

It’s a lovely recruiting tool, but it’s mostly just words on a wall. Employer branding lip service. Organizations want to preserve the illusion of trust, but without giving people real freedom.

My former boss used to call this empowering with permission, but without action. Where companies give people more responsibility, but with the caveat that they still need to obtain an unreasonable number of signoffs to get anything done.

It’s like, here, do whatever you want, as long as I approve everything.

Sorry, but that is not freedom, that is slavery.

If leaders were intelligent, they would only have one core value.

Trust people to use their best judgment.

Everything else falls into place, and you won’t need a ton of process to weigh it down.

Will this new process scale and replicate across the team?

Some processes are born with good intentions, but never get updated to match the current organizational reality. Processes become static while the business changes around it.

And to be fair, you don’t know the answer to this question until after the fact.

I remember passionately pursuing an internal wiki project at one of my companies. In my opinion, it was the right solution for our knowledge management problems, but at the wrong time. Because we should’ve been practicing tight documentation from day one.

But the time I got hired, employees were too entrenched in their old, disorganized habits. Hence, I was the only person who used the internal wiki. It helped me do my job better, but it didn’t scale.

As we added new employees and customers, there wasn’t widespread adoption cross the company. Which meant I had to perform all the updates. Nobody else was taking the time to iterate as our organization evolved.

So much for process.

In sum, let’s revisit our questions.

  1. Will this process create autonomy that boosts speed, or enable dependency that slows us down? T
  2. Will this process require an investment in infrastructure that’s expensive and takes time and energy away from creating value?
  3. Does this process eliminate multiple downstream problems, or create more of them?
  4. Will this new process empower and simplify, or control and overcomplicate?
  5. Will this new process scale and replicate across the team?

As a reminder, a little bit of process will set you free, but too much will crush you. Use these questions to strike the balance.

How will your team decide how much process you realistically need?