Expanding the concept of “team”
What happens when a user of your application makes a mistake that has negative repercussions? Let’s say this was not a conscious mistake or an act of negligence, it was just an accident, a simple typo, or clicking the wrong button. Whose fault is it?
Is it the user’s fault for being too careless? Is it the developer’s fault for designing a system that doesn’t protect against such mistakes?
What if we’re asking the wrong questions?
This happened to me recently and a light bulb went off in my head. The reason I was asking the wrong questions was due to the way I was viewing my relationship with the users of my application.
Go read those two questions again.
Is it the user’s fault for being too careless? Is it the developer’s fault for designing a system that doesn’t protect against such mistakes?
The key word is fault. We get so obsessed about figuring out who is responsible for a mistake. What if my mistake was not expecting fallible people to make mistakes?
We say things like, “It’s the users’ job to make sure the data is correct.” Maybe it’s their primary responsibility to make sure the data is correct. But when the data is wrong, IT ends us getting partially blamed.
He’s the crux of the matter – you and your users are on the same team. This changes everything.
Shared responsibility
Everyone is responsible for quality, whether that’s the quality of the code, the way that the system is used, or how people consume the data downstream. This doesn’t mean that it’s all on you, but as a member of a software development team, you are a part of the process.
With that being said, what can you do to ensure that the system is used correctly? You could build checks into the system, write audits to check for issues, educate users on how to use the system better, and be aware of how changes to the application might affect people that use it or consume the data. More importantly, you care about all of these things and don’t dismiss things as someone else’s problem.
Care about what your users care about
You know that feeling you get when the smartphone app that you love releases a new version with a fancy UI redesign, more features, and promises of rainbows and unicorns, yet you hate it because it’s slower and the new features make it harder to use it in the way you like? This happens to me all the time!
That’s probably how your users have felt more than a few times. You probably didn’t mean to do it. But it probably happened because you didn’t know the repercussions of your design decisions.
I just spent two months being a user of my application. Not as a tester or a coder, I joined the users’ team. I sat on their floor, I went to their meetings, I did their job along with them. Now I often used SQL to solve problems, but I lived their life and watched how they did things. I had several moments where I groaned because I had to wait for the next release for something to be fixed, and I realized there are many situations where the system doesn’t allow a user to do something the “right” way and they have to find less than optimal ways to get their job done. I saw them spend days doing mind numbingly boring repetitive tasks because IT didn’t have time to help them.
The reason I ended up joining the users’ team is that we wanted to break down the walls that caused all of these inefficiencies. Many of you have had the aha moment when your developers and testers start communicating and owning quality together and you are able to drastically streamline the software development process. We applied to same principle of working together to drastically streamline the business process as well. And along the way, it shifted my mindset as well.
I’m not there yet, but I’m starting to get a better grasp (maybe even a good grasp) of what my users care about. I’m not sitting with them doing their work anymore, but now I go up and ask them a lot more questions, we’re doing more training and user acceptance testing, and I can relate when they have struggles. But even more importantly, the users are starting to realize that I get it.
Prioritize your users
One thing that surprised me when I sat with the users is how many system issues they knew about that I had no idea existed. “Why didn’t they just tell us?”, I would think. Sometimes they would create tickets for us to fix them, sometimes they might send an email, but the tickets often got lost in the backlog and the issues wouldn’t get resolved. So they just stopped telling anyone about the issues because they felt that no one was listening.
How frustrating! Believe me, in IT we were getting A LOT done. But we weren’t prioritizing our users, and they didn’t think they could count on us.
The other day, I got an email from one of the users explaining some problems they were having. I was ecstatic! They took the time to write that email because they actually think that it might do some good.
I can’t always drop everything to cater to their every whim, but we need a process that will allow users to raise issues and get them resolved. What’s the point of releasing all kinds of new functionality if the existing functionality isn’t sufficient?
I’m hoping to be much more available to the users so that they see me as someone that they can count on. That doesn’t mean just waiting for them to raise issues, but also proactively trying to find issues, show them how they can use the system better, and even volunteering to assist when I see a way that we can use technology to help them do their jobs.