Process Doesn’t Burn People Out, People Burn People Out
I can hear you grimacing from here. I get it, “process” as an amorphous concept carries a lot of baggage. So let me clarify my thesis real quick: process is neither inherently good or evil. Whether it is used to benefit an organization depends entirely on the people who shape and interact with it.
What do I mean by process? In this context, simply the framework(s) a person, team, or organization uses to optimize results. That could be some kind of Scrum model with all the ceremonies involved and commonly tracked metrics therein, or something as loose as a two-person operation moving handwritten Post-it Notes across their living room wall as work progresses. It could be anything, honestly.
What I’m most interested in exploring over a series of posts are the events, behaviors, or actions that in my experience will commonly lead to clashes between people and process. Because, regardless of an organization or team’s framework, some problems will come up. Maybe not even “problems,” but inefficiencies, whether immediately or over time, that will have a noticeable impact on project results.
Chapter 1: Apathy
First up: laziness with regard to shared practices or processes. This one’s pretty self-explanatory, but still important to recognize and address. Even one person on a core team being complacent about process can have impacts far beyond that team member just requiring more attention from Project Management.
For starters, someone ignoring or being lazy with process is unfairly placing their share of the process burden on the rest of the team. They might not even realize that their actions are forcing others to pick up the slack. Whether that’s the project manager, a software developer, or the rest of the team, someone is going to be doing extra work.
Worse: this behavior sends a signal that it’s ok to ignore process when you don’t like it. That’s not a message that builds effective teams. Problems or concerns with process should be put in the spotlight as quickly as possible. It can be uncomfortable delivering what might be perceived as critical feedback, but simply ignoring annoyances covers up valuable conversation that could benefit the entire team.
Further, if someone is apathetic about following the practices your team has established, chances are pretty good that’s a symptom of a larger issue. Maybe even one of the issues I’ll be discussing in future posts in this series.
The good news is that hiding inside every problem is an opportunity for growth, learning, evolution. Dare I say…iterating.
A good question to start with in overcoming apathy is, how many people feel this way? If it’s unique to an individual, simply talk with them to understand the issue. More often than not, pain points within process are completely solvable, but not if you don’t take the time to understand what the problems are.
And, honestly, it’s completely possible that someone being complacent about process doesn’t even realize it. Have a lot of changes in direction or resourcing happened on your team lately? Has process ever been collectively discussed and explained? Is the person in question divided among multiple efforts with different process intricacies?
On that note, consider setting up a retrospective with the entire team, especially if more than one individual is getting process malaise. If you’re already doing them, use your next one to focus on this issue specifically (or just set up an ad hoc meeting for this purpose).
Whether one or many people are operating outside the lines of your collective process, it’s valuable for the whole team to hear: a) that it’s happening; b) why it’s happening; c) what’s going to be done to improve it.
Finally: regardless of the root cause(s) or the action plan you and the team put in place, make sure to follow up. Otherwise, you will have become another example for this post.
Tune in next time for a riveting read on Big Brother; aka Metrics, A Cautionary Tale.
DockYard is a digital product agency offering exceptional user experience, design, full stack engineering, web app development, software, Ember, Elixir, and Phoenix services, consulting, and training.