One of the patterns we see over and over again at DevMynd is urgency leading to failure. Urgency crops up in many different ways and for many different reasons, but the end result is almost always a negative outcome.
First, let’s define what I mean by urgency. I’m not talking about the justified drive to complete a goal or the normal desire to meet deadlines. I’m talking about the frantic, haphazard, whirling dervish kind of urgency. When the product manager storms into the development room and whips everyone into a frenzy because “literally everything has changed”…that’s the kind of urgency I’m talking about.
I think most people understand this at some level. We intuitively get the fact that if we don’t approach problems with a measured, evenly-paced response we’ll probably see poor results. So why then do we so often allow ourselves to fall prey to urgency? I can’t answer that, but I can share some of the impacts that we see.
Impact on Products
If you’re in the field of delivering digital products to consumers you know that every piece of the puzzle is critical to overall success. If the design and UX aren’t right then users get frustrated. If the code is poorly written then bugs crop up and maintainability drops. If the marketing and product fit aren’t right then visitors don’t convert to customers. Urgency hurts all of these.
Design and UX
Sometimes it’s really hard to tell when a design team feels urgency. But, if you look closely and read between the lines you can always tell. It often comes out in that sense that someone isn’t fully satisfied with their work. Design and UX is something that needs to percolate, people need time to think, time to throw ideas away before arriving at a place of contentment with a solution.
Code and Architecture
As much as urgency hurts design, it’s devastating for code and architecture. When developers careen towards a solution rather than considering options, asking questions, and consulting with other members of the team what you get is sloppy. Often the most beneficial practices (Test Driven Development, pair programming, code review, etc) are abandoned when developers feel pressured. This is 100% the worst thing that can happen, leaving these methods behind exponentially increases the problems.
Overall Product
A product suffers greatly from the downstream effects of urgency. The primary symptom I find is inconsistency and misalignment of user needs with product capabilities.
Impact on Teams
Organizationally there are many chronic issues created by a culture of urgency. For development and design teams these issues lead to an overall sense of unhappiness which in turn leads to high rates of attrition. If you have a lot of turnover on a team and otherwise have a generally good culture, urgency could be a contributing factor.
Many times in my career I’ve worked as a consultant on teams and heard from client folks that they feel anxious when arriving at work in the morning. They know that when they pop open their email, coffee cup in hand, they’re going to be awash in “holy shit everything is on fire” emails. Nobody wants to work in that environment, and it doesn’t motivate people to do good work, and consequently this breeds more urgency.
Some Sources of Urgency
Many things can incite this kind of frenetic energy and there’s little chance that I’ll be able to list them all here. A few common sources though that I’ve seen in the past.
Ambiguity or Misunderstood Expectations
Ambiguity around expectations is a breeding ground for urgency and uncertainty. When people don’t know what is expected of them they tend to move either faster or slower. Slow is bad, but in this particular case it’s the better choice. Faster is problematic because it leads to all sorts of shoddy work being done without purpose.
Perceived vs. Actual Risk
This is a big one, and probably the one I see most commonly. If you’ve ever been on a project where the managers post up a deadline based on some looming event you know what I mean. It could be something promised to a key customer, a trade show, or a thousand other flimsy reasons. I’m not implying that there are never cases in which a deadline exists because of some external force, but in my experience it’s almost always overblown.
That customer promise is likely something that can be moved, that trade show is probably not nearly as important as the sales team thinks it is, the CEO who wants this release out before she goes on vacation…tough cookies. If these kinds of influences pop up, ask yourself what is the real risk and then weigh that risk against the cost of urgency.
Team Fatigue
It might seem counter-intuitive that a worn out team would create a sense of urgency but it often does. A burnt-out team is a sloppy team, they will quickly develop the “let’s just get this done” attitude which is a sure-fire way to throw best practices to the wind.
Becoming Less Urgent
Learning to combat or at least cope with urgency is the tough bit, and I’ll admit, I’m not great at it. That said, here are few things that we’re working on with our teams at DevMynd.
Delayed Reaction
I’ve noticed that one of the things that fosters urgency is quick reactions to drastic changes. When that product manager suddenly asks for a totally new feature set than what the team has been working on it’s better to step back before reacting with surprise and knee-jerk solutions. Avoid being reactive, rather step back and strategize a bit before moving forward when a monkey-wrench is inbound.
Evaluate Risk Objectively
This one is hard, because stakeholders often have a different perception of risk than a construction team might. That said, it’s helpful to know what the real cost is of missing that trade show, or asking a customer to push a deadline. Often the mess created by rushing is not nearly worth the risk of missing an external milestone.
Make Smaller Commitments
When progress “feels” more constant, urgency tends to go down. Even if the overall volume of work accomplished in a week is lower, the consistency goes a long way. Working in smaller units that can be demonstrated independently helps everyone see that things are moving and generally comforts the most frenzied members of a team.
Intentional Breaks in Flow
I like to think of this one as pulling the rip-cord on a parachute. If you jump out of a plane, you’ll keep accelerating until you pull that cord, which pauses that acceleration. A quick 10 minute team YouTube break in the afternoon, or a 5 minute coffee break from a heated meeting goes a long way to interrupting the flow and controlling the acceleration towards urgency. If you’re a productivity geek (or just enjoy tomatoes) you may also take a look at the Pomodoro technique.
Perspective
Ultimately it’s all about perspective. If you can find a way to step outside of the situation and view the forest a little more and the trees a little less you’re likely to begin letting go of the urgency. You realize what’s really important in the medium and long term and stop making decisions purely based on immediacy. It’s a tough skill, but a necessary one.
