The Infinite Feedback Loop of Building Software

 
The Infinite Feedback Loop of Building Software to test/verify, deploy/release, code/build, analyze/plan, and user feedback/monitor
 

I can't make everyone truly happy with what we are building on the software side.

I help oversee our website, app, people management system (Rock RMS), and several other software experiences that affect everyone who attends our church. I also help lead platforms that volunteers and staff use regularly. In short, I receive a lot of feedback about what is working, what isn’t, and what people think we should build next. That is the nature of technology. Everyone has an opinion because everyone is a user.

The challenge is that most people experience software through their own specific needs. They usually aren't thinking about every type of user, the cost of a request, the time it would take to implement, or the other priorities already in motion. They are thinking about what would make their experience better. And honestly, that makes sense. If something could make someone’s work easier, save them time, or solve a problem they regularly face, they'll bring it up. But when you oversee software, you have to see the bigger picture.

Software is never really finished. There is always more to build, more bugs to address, more systems to improve, and more ideas to consider. A new platform, tool, or feature could always help someone do their work more effectively. It can feel like you are always chasing another rainbow, hoping that the next improvement will finally make everyone happy. But once you reach that point, there is always something else to chase. Some people will love the improvement, while others will immediately have feedback about what should come next. At times, it feels like an infinite loop. Over the years, I have learned a few things that help me navigate that reality.

Feedback is valuable, even when you cannot act on it

Feedback is one of the best ways to learn what is working and what is not. Sometimes a user is wrong, or their proposed solution may not be the right solution. But that does not mean their feedback is unhelpful. Often, the feedback reveals a real frustration, a confusing experience, or a problem you may not have seen from your perspective.

When you listen well and address the right feedback, you can win people over. You create fewer negative experiences and more trust in the work you are doing. Over time, that trust matters. People become more willing to support the direction you are taking, even when you can't complete every request right away. Of course, you shouldn't prioritize every request. You still have to weigh the value of the feedback, how many people it would affect, the effort involved, and the timing. You have to decide whether to do something now, later, or not at all. That is not always easy.

I try to remain open-minded when someone gives feedback, even if my first response is defensive. Sometimes I need time to think about it before I can see the value in what they are saying. But I have learned that defensiveness can keep me from seeing a real opportunity to improve the experience.

A bigger plan keeps you from chasing every request

Listening to feedback matters, but you can't let every request determine your priorities. That is why a multi-year plan matters. Without one, the loudest request, newest idea, or most urgent-looking problem can easily take over your attention. People will always want a shiny new thing that could improve their personal workflow by 1 percent. If a change could make their job easier, they will ask for it. Again, that is understandable. But your job is to weigh those individual needs against the organization’s larger goals.

For example, when I stepped into my current role, we needed to transition our people management system. That system powered much of our website and app ecosystem, and we also had technical-stack issues that needed attention elsewhere. It was a significant project and, for about eight months, it was the most important thing we could work on. During that season, volunteers and staff still brought great ideas. Some of those ideas would have improved their workflows. But I often had to tell them, “I love that idea, but this other work is more important right now.”

That is part of the responsibility of leading software. You have to balance competing needs and identify the work that will help the organization most in the current season. Long-term goals give you a filter for making those decisions. They help you stay focused while requests, bugs, ideas, and unexpected problems keep arriving in your inbox. This is easier when you have a clear, large project in front of you. It gets harder during the normal month-to-month rhythm, when every request feels reasonable on its own, and there is no clear finish line.

Better feedback comes from better conversations

One thing I think we can do better in software is help users understand the cost and time behind their requests. Most people do not know what it takes to turn an idea into a real feature, workflow, or experience. They may not see the design work, development time, testing, training, support, maintenance, and potential impact on other systems. That is not their fault. They are simply sharing what would make their experience better. But helping people understand those tradeoffs can improve the quality of feedback. When someone brings an idea, invite them to think through it with you. Ask questions that help them see the bigger picture.

How many people would this affect? How often would they use it? What problem would it solve? What would happen in unusual situations? Would it help us reach one of our larger organizational goals? Is there a simpler solution that solves most of the problem?

The goal is not to discourage people from sharing feedback. The goal is to help them move from dreaming about an idea to thinking through whether it is worth pursuing. I have found that this makes conversations more productive. Sometimes the person realizes the request is not as important as they first thought. Other times, they come back with a much stronger idea because they have considered the practical details. Either outcome is helpful. I want feedback, but I want it to be constructive feedback that helps us make better decisions.

Some problems are not requests

Of course, not all feedback is about an idea or a feature. Sometimes the software simply breaks. That is one of the difficult realities of supporting systems that need to be available all the time. When the website, app, check-in system, registration flow, or people management system is not working, people feel it immediately.

It is a little like electricity in your home. It does not matter that it works 99.9 percent of the time. When it is out, that 0.1 percent becomes the only thing anyone notices. That is the burden of software. It touches people constantly, which means even a short disruption can create frustration. You cannot eliminate every issue, but you can build systems, processes, and habits that make failures less frequent and recovery faster. You learn from the outages, improve the weak points, communicate clearly, and do everything you can to make sure those moments remain rare. And if you work in the faith space around software, you know there are few worse times for something to break than Sunday morning.

The work is never finished

The feedback will keep coming. There will always be another request, another improvement, another bug, and another opportunity to improve the experience. That is part of the job. The goal isn't to make everyone happy with every decision. That is impossible. The goal is to listen well, prioritize wisely, communicate clearly, and keep moving the most important work forward.

Software may never be finished, but it can always improve. That is what makes the work challenging. It is also what makes it meaningful.

Jay Kranda

Jay Kranda is the Innovative Tech Pastor at Saddleback Church

http://jaykranda.com
Next
Next

Animator, Skateboarder, Pastor