Emerson Taymor
Even dietitians know it’s healthy to have a beer or a donut once in a while. Without wiggle room, a strict diet can harm health in other ways, like creating stress or limiting social interaction.
Until a client prescribed otherwise, our company struggled to take a break from something that was supposed to keep us strong: our process. This client loved our work, but he felt that we’d become too married to our own way of doing things.
A look back at our client data showed that we had, indeed, taken our healthy habits too far. We did our best work when we eliminated VUCA (volatility, uncertainty, complexity and ambiguity), empathized with our clients as well as their users, and pushed toward consistent shipping.
So we broke our mold.
We started incorporating stakeholder personas into the mix, which we use to remind ourselves that the client’s business success matters as much as the user’s ultimate experience.
Today, when we realize that achieving a certain business outcome requires us to go off process, we put our Process Kool-Aid down and do it.
Too Much of a Good Thing
A process is a healthy thing for a business to have. Some startups struggle mightily to find and follow one. But when a process saps a project’s momentum or creates analysis paralysis, it’s time to take a break.
For example, user research is an important part of the process for any company building something for people. But sometimes, designers become so familiar with a problem or project that user interviews become a waste of time.
Other times, it takes a prototype to validate a particular user assumption, so an experiment-driven design may be the best way to move forward. Experiment-driven design’s “hypothesis, ideate, make” cycles champion building over traditional research tactics as the best way to check assumptions.
User research is just one example. Companies can get stuck in their processes in all sorts of ways. On agile teams, for example, scrum masters sometimes forget just how much time those daily checks and meetings can take. Not only are daily meetings unnecessary for truly agile teams, but they can also quickly cut into the team’s sprint schedule.
To be clear, the problem isn’t agile itself; it’s a misunderstanding of the Agile Manifesto’s core principles. Across every version of agile — scrum, SAFe®, Kanban, you name it — those core tenets are what actually drives progress.
Agile promotes adaptability, collaboration, and frequent iteration; it measures progress in terms of software production, not in meetings held or key performance indicators met. Each meeting a team of makers attends pulls its members out of that all-important flow state. Constantly switching back and forth between “work mode” and “meeting mode” can kill their agility and create frustration.
But the answer to an overabundance of process isn’t to eliminate it entirely. Pushing forward without measurements in place or keeping makers out of the loop is unproductive at best and counterproductive at worst.
Instead, think: Which meetings can be killed? Which communications can be handled via email or Slack instead? Can the sprint planning meeting be moved to Monday morning to reduce context switching? Use a light touch. Too many cutbacks at once can create chaos.
When to Pull Back on Progress
Just as important as keeping process in check is preventing runaway progress. To see the problem with unchecked progress, picture a footrace. Unlike most races, this one doesn’t have marked paths or even a finish line. The runners take off, but they don’t know where to go or when to stop. What should have been a straight shot to the finish turns into a mad sprint in every direction.
In the world of business, this dash might look like a team that consistently builds the wrong thing and never seems to hit pay dirt. Because team members didn’t bother to understand why they’re building what they’re building, they waste time creating things that the product’s users won’t want.
If you have tons of work to show but your core metrics are lagging, then it’s probably time to rein in progress. If you don’t, you’ll burn through your capital and wind up with something nobody wants, which doesn’t exactly inspire confidence in investors or clients.
Hitting a little too close to home?
Govern progress with a research-based approach. Start by defining the user’s problem and choosing key metrics carefully.
Then, build prototypes around those user insights. You may not move quite as quickly, but you’ll meet more benchmarks and satisfy more clients.
Not every team has a process or a progress problem, but most could use a better balance.
So eat your greens — in other words, have your processes — but don’t say “no” to that big, hearty helping of progress when you’re hungry for it. Just don’t overdo it.
Also worth a read:
No comments yet.
Upgrade to join the discussion.
Already a member? Login