Why Cloud Computing

It Started With a Question

I spent years doing work I was genuinely good at. Managing complex claims, talking to policyholders in some of the worst moments of their lives, coordinating between engineers, contractors, and attorneys to deliver outcomes under tight deadlines. I developed real skills: structured communication, risk assessment, stakeholder management, problem-solving under pressure.

But somewhere along the way, I started asking a different question: What if I could apply these same skills to something that scales? Something where the problems are bigger, the stakes are higher, and the impact is compounded across thousands of users and organizations at once?

That question led me to cloud computing.

What I Discovered

The Timing Was Right

Cloud computing was transforming how every organization (from startups to government agencies) built, deployed, and scaled technology. I saw that the skills already in demand weren't just technical. Organizations needed people who could translate requirements into architecture, communicate trade-offs to executives, and guide customers through decisions. That description sounded familiar.

People Are Still Central

What I value about Solutions Architecture specifically is that the technical work is inseparable from the human work. You are always designing for someone: a customer, a team, an organization. Discovery meetings, architecture reviews, and executive presentations all require the same communication and empathy skills I developed working with customers through difficult situations.

The Technical Depth Is Genuine

I did not come to cloud looking for a shortcut. I started with data analytics, moved to Linux fundamentals, enrolled in WGU's Computer Science degree, earned the AWS Solutions Architect Associate certification, and built real architectures using Terraform, EC2, Lambda, RDS, CloudFront, and more. I wanted to earn my place in this field, not just claim it.

Scale & Impact

In my previous career, I helped individuals and families recover from property losses. That mattered. In cloud architecture, a well-designed solution can protect the data of millions of users, save an organization thousands of dollars monthly, or enable a startup to launch in weeks instead of years. The scale of impact in cloud is unlike anything else in technology.

Why Solutions Architecture Specifically

When I discovered Solutions Architecture as a role, I recognized something immediately: it described work I had already been doing, just in a different domain.

A Solutions Architect gathers customer requirements, designs systems that meet those requirements, explains trade-offs to stakeholders who may not be technical, navigates competing constraints like cost, performance, and security, and guides customers to confident decisions. That is exactly what I did as a claims adjuster: gathering requirements from multiple parties, assessing risks, explaining technical findings in plain language, and delivering outcomes under strict timelines.

The difference is the medium: instead of property and insurance, the medium is infrastructure and cloud architecture. And I find the infrastructure problem genuinely fascinating.

"I did not change careers because my previous career was failing me. I changed because I found something that could use everything I had already built, and take it further."

What I Learned During the Transition

🧩

Systems Thinking

Cloud architecture forced me to think in terms of interconnected systems, failure modes, and cascading effects. This deepened my analytical skills beyond what any previous role had required.

📐

Design Trade-offs

Every architecture decision has trade-offs: cost vs. performance, availability vs. complexity, managed vs. self-hosted. Learning to reason about these openly changed how I approach every problem.

🔐

Security as a Default

Designing secure-by-default systems (encryption at rest and in transit, least-privilege IAM, private subnets, WAF rules) gave me a new lens for thinking about risk, one I now apply everywhere.

📝

Writing for Engineers

Architecture documentation (diagrams, decision records, runbooks) is a different kind of writing than claim reports or customer letters. Learning to write clearly for technical audiences sharpened my communication significantly.

⚡

Terraform & IaC

Learning to express infrastructure as code was a turning point. IaC made architectures reproducible, auditable, and version-controlled, and gave me a mental model for treating infrastructure like software.

🎯

Business Alignment

The Well-Architected Framework reinforced something I already believed: technology decisions must always connect back to business outcomes. Cost optimization, reliability, and performance exist to serve people, not as ends in themselves.

Where I Am Going

My immediate goal is to join an organization as a Solutions Architect, Solutions Engineer, or Cloud Engineer where I can contribute quickly while continuing to grow. I want to be in rooms where customers are describing their technology challenges, and I want to be the person who can connect what they need with what is possible.

Long-term, I am working toward Enterprise Architecture: designing cloud strategy and governance frameworks at scale, advising executive stakeholders, and shaping how organizations approach cloud adoption. I think my combination of business education, customer-facing experience, and hands-on technical work gives me a foundation most people in that space do not have.

I am not claiming to have arrived. I am claiming to be on a deliberate, well-documented path, and that I have the drive, the skills, and the track record to make the most of the right opportunity.

See My Full Timeline → Let’s Talk

Why I Chose Cloud