Several years ago, I worked for a nonprofit that did event-based fundraising. We purchased a new all-in-one software service that ran both the back-end fundraising and participant database, and our front-end event website, where participants could have a profile page and accept online donations. Because it was an all-in-one package, the way you configured each end affected how the other end functioned. Changes to any part of the system caused ripples to other parts. My job was to set up and configure the software, and provide tech support to participants.
The back-end database wasn’t easy to use: overly complicated, nonintuitive workflows. A colleague who worked in the accounting department, and who only interfaced with the back-end database, came to me with a list of things she hoped I could reconfigure to improve the workflow. I looked at the list and realized these changes would alter the participant front-end in ways that would make it much harder for people to use.
So I said no.
My colleague agreed when I showed her what the impact would be. We couldn’t make it harder for participants and donors in order to make our jobs easier. Better we deal with the difficulty than them.
I think about this whenever we look for ways to make our jobs easier. It’s totally fine to want to make our jobs easier, but there are going to be ripples that affect other people, either customers or colleagues. We need to be aware of how our workflows affect someone else’s, especially if we make their job more difficult in order to make ours easier. We need to consider whether that’s really what’s best for customers and the organization, and not just whether it’s best for ourselves.
Sometimes our job is just going to be hard.
Continue reading “Sometimes Our Job Is Hard”
