Shifting Into a Bigger Role

In 2019, our backend development team moved from being part of a communications group to being fully within the University Advancement tech team. That change brought a lot with it. One of our developers left. We had to shuffle workloads quickly. Then COVID hit, which added its own complications. Hours were reduced for a while, priorities shifted, and we focused on keeping essential systems running while slowly tackling technical debt.

By then I had already been looking beyond day to day development and thinking about how our systems fit together and where they needed to go next. My new manager saw that and encouraged me to step fully into shaping the whole product. He wanted me to spend more time guiding architecture, planning how things connected, and preparing us for the future. That meant documenting our solutions, improving how we deploy, and setting clearer guardrails around change management so we could move faster without losing stability.

Stabilizing the Foundation

One of my biggest goals was to make things solid underneath. I chased down recurring errors and fixed them. I built dashboards so we could see what was happening with our systems in real time. I added security checks to code review. I made sure all custom code was in version control. Even our AWS setup went under version control so every infrastructure change could be tracked. We shut down old servers, upgraded PHP, and worked through lingering security audit items.

None of that work was exciting, but it was absolutely necessary. It gave us a steady base we could build on and freed us to think further ahead instead of constantly reacting.

I had already been managing projects end to end, and during this time that responsibility grew. I continued moving sites into WordPress, including major events like Hit the Bricks and Wake ‘N Shake. That meant working with vendors, clarifying scope, and making sure deadlines were realistic. Each project pushed me to refine how I anticipated risks and smoothed the way for better, faster delivery.

Thinking and Building at a System Level

As the dust settled, I focused on making our development team more mature and predictable. I standardized how we handled AWS changes. I improved deployment workflows and brought in better tools. I pulled project tracking into one place so planning and communication were simpler. I also stepped into the Scrum Master role for the Wake Network team, helping organize sprint planning and reviews.

These changes made our work steadier and easier to trust. They also gave us room to plan further ahead, knowing the basics were reliable.

My work had always supported the university’s fundraising and engagement goals, and during this time that connection deepened. I co-led efforts to bring giving into Wake Network, helping shape how donation forms and payment acceptance were added and guiding decisions so the work would support future campaigns and donor needs.

I also got deeper into architecture decisions. I helped with the Gutenberg migration to reduce technical debt and improve performance in WordPress. I built serverless workflows, strengthened CI/CD pipelines, and added automated checks to keep code safe and maintainable.

Growing Into Strategic Influence

Looking back, that time was a turning point for me. I had already been thinking like a product architect, but this period gave me the space and recognition to grow fully into that role. I learned to balance doing the work with shaping the bigger picture, making sure the choices we made would support what was coming next. I began influencing not only how we code, but how we organize work, guide priorities, and invest our time. Becoming a product architect gave me the opportunity to intentionally shape the foundation we will rely on for years to come.