My approach in action.

My first technology project began with one instruction: find out why participant communications weren’t being sent as intended. I was given the name of an application I had never used and had to determine where to start.

I had the application installed and spoke with its users to understand its purpose and how they worked with it. Documentation was scarce, so I searched the available records for clues about its original design. That search led me to someone in another department who shared what he remembered and the documents he still had. Without the original requirements, I pieced together how the application worked through research and testing.

I identified a configuration issue, documented the cause, and presented my findings to management. They entrusted me with a budget and a technology team to define how the application should work and lead the changes.

Working with the technology team, I turned my findings into requirements for the solution. I also created documentation and training materials to guide the setup team through configuring plans correctly in the application. I trained them on that setup process, including how to prevent mailings from going out before a plan’s go-live date and how to verify that the mailings had been sent.

With the changes and training in place, the issue did not recur. The project gave me my first experience taking a technology solution from an unexplained business problem through investigation and delivery, while preparing people to use it successfully.

When I noticed a newer developer struggling with his tickets, I wanted to understand where he was getting stuck. Production support work requires tracing through unfamiliar code, identifying what it's doing and where it's going wrong. Training provides a foundation, but learning how to approach that analysis takes practice and guidance.

This teammate often worked a different shift, so we hadn’t had many opportunities to talk. I stayed late on several occasions specifically to check in with him. We talked about work and other things, and as I got to know him better I began to understand what he found difficult. He needed more guidance on where to begin his analysis and how to keep moving when he reached a dead end.

I worked with our offshore management team to pair him with a tenured developer who could help him work through those moments. I stayed involved, too, encouraging him to reach out when he needed help finding an answer. I helped where I could and connected him with others when he needed deeper technical guidance.

Over the next few months I started seeing progress. By around six months he was doing considerably better. Nearly a year later I’m impressed by the work he’s doing. We helped him get the guidance and support he needed to develop his skills and do the work successfully.