The technical revolution in the last half century has changed our lives in many areas, and software development in general is one of the most significant. After working over 40 years in and with credit unions, there have been many changes in my perspective of serving members and the tools we use to accomplish that service.
From my short stint as a credit union teller, to working in accounting and financial management, and finally, working for a CUSO in the development and testing process of credit union toolsets, I have learned much about how different people with various roles think about tools, their function, and what it takes to develop and maintain them.
The introduction of new tools
When I started in the industry (and I know I’m aging myself), we were at the beginning of the computer age and most everything we did was manual. Tools then included pens, calculators, phones, typewriters, dumb terminals, passbooks, and a huge mainframe for processing, some done in a batch environment. Member service was almost always face to face and it took time to help each member with their transaction. We didn’t question the steps needed to complete something for the member; whether it be writing receipts, typing checks, updating balances in passbooks, etc., we just did the work.
As we moved into online processing and a more automated environment, new tools helped us eliminate some of the manual processes so that we could serve members better in the lobby or on the phone, focusing on them rather than on menial tasks. We still expected to drive the process of transactions but were amazed when we had the ability to eliminate some of the tedious work. Frankly, it was an exciting process to watch unfold.
What was once special becomes standard
Over the years as we got used to automation in the industry, the focus on tools changed as did the expectations of what they should do. The initial thrill of the automation became more of an expectation. As a teller and as an accounting clerk, I was focused on my individual task. When it came to tools and software, I cared about how much data I had to enter to process a transaction or journal entry, how many screens I had to move through, and how much time it took to make an adjustment or record a transaction. My wish list for tools was narrow and focused on very specific tasks. My expectations rose along with the speed of the tools, always wanting them faster and more efficient. However, my requests for change were often due to a minor irritant in the process and would rarely improve the service to the member.
As I worked into management, my perspective on tools began to shift and broaden. I started to think about what additional data would be helpful to have in the system, how we might want to process or configure new products differently, and how we might change processes to fit our credit union procedures and policies more directly. However, although I have a pretty analytic mind, I have to admit that I didn’t really understand the scope of software development and what effort was needed to make something work differently. My vision was broader than before, but understandably still focused on my area of responsibility, our institution, and how we were used to doing business. I also did not take into consideration how changes might impact existing processes or how it may impact others using the software in a slightly different way.
Different departments, different perspectives
When I started working in the quality control area, I had to make a mental shift as we verified new software and reviewed client requests for changes. With my credit union experience, I considered myself the ultimate user advocate – someone that understood where the requests were coming from, how the work was done in the credit union, and also wanted to deploy “perfect” software. On the other hand, I had to become a part of the cooperative environment by listening to varying opinions from multiple credit unions, considering how more than one financial institution will do their work and determining how different types of offered products with varying configurations would be impacted by changes in the software. Ultimately, my experience was and is helpful as I still try to act as a user advocate, but I also understand that I am only one voice of many with varying opinions.
I’ve learned a lot over the years about the effort it takes to envision, plan, develop, and document new functionality. It takes a team with varying skills to design new software including dreamers to envision something new, those with the ability to foresee and create a process, technical minds to make things happen, analytic and detail minded individuals to make sure that the end result is valid and practical, and those that can carry out the documentation and support of the end product. However, maybe even more unexpected, I have learned the cost of a “minor” adjustment – making a change to eliminate a click, add a new piece of data, change the flow of a screen, or eliminate an “irritant.” What often seems so simple on the surface can often take more development time than one would anticipate or add more risk than one would expect.
In addition, each time we make small adjustments, it takes resources away from efforts that drive the future. I no longer dream of a “perfect” software as the opinions of users are so varied.; I now dream of making the most of our resources to develop a great software, one that will be valuable to members, credit unions, and their plan for continued success in the future. Sometimes this involves making hard decisions to leave behind a few of those “irritants” in lieu of moving forward with new ideas for the future.
Keep it focused on the member
In the end, no matter what role we play, our vision is basically the same – to serve members and continue to allow credit unions to succeed in their role of keeping the credit union cooperative alive within their memberships. With a community of people in multiple roles, we get varying requests for changes in software. From the front line employees with direct access to the member, the task oriented staff with ideas for efficiency, the business leaders with ideas for new business initiatives to the dreamers that allow us to dream big for the future – all have important roles to give feedback on how best to drive our software tools. However, in the long term, we need to balance our objectives to assure that we’re ready to meet our members needs and prepare for more changes in the coming years.
