So... What Am I?

One thing I’ve struggled with recently is figuring out what to call myself.

During my almost 15 years at Gimmal, and now Morae after the acquisition, our engineering career ladder was pretty simple. We had Junior Software Engineer, Software Engineer, Senior Software Engineer, and Architect. Later we added Site Reliability Engineer, but that was a completely different path.

Now I look around the industry and see titles like Staff Software Engineer, Principal Software Engineer, Platform Engineer, Cloud Architect, Solutions Architect, Engineering Lead, and half a dozen others. While my head was down helping the company and doing my job, the industry added a lot more labels.

My official title has been Cloud Architect for several years, but is that really what I am?

When I think of an architect, I picture someone producing polished diagrams, speaking some architectural language I’ve never learned, referencing frameworks like TOGAF (which, honestly, I don’t even know what it is), and operating at a level above the code. I picture someone sitting in an ivory tower, handing down architectural decisions from above without necessarily being involved in the messy details of implementation.

I’ve never wanted to be the person who just draws boxes and arrows and tells other people how things should be built. I still enjoy writing software too much. I still like getting my hands dirty. I like understanding the details, working through the problems, and being close enough to the code that I know whether the ideas we’re discussing actually work.

I’ve architected products from the ground up. I’ve designed and built proof of concepts that became real products. I’ve built most, if not all, of our CI/CD pipelines. I’ve worked alongside our SREs on infrastructure and operational improvements. I’ve used Terraform to build and tear down complete Azure environments. I’ve modernized legacy applications, migrated workloads to newer Azure services, and helped design and implement every facet of our multi-tenant SaaS platform.

I’ve spent weeks on spikes where the goal wasn’t to build anything yet, but simply to come back with answers. How should we integrate with Microsoft Graph? Which authentication protocols should we support? What’s the best way to migrate our ARM templates? Is there a better Azure service for this workload? Those are the kinds of problems I’ve always enjoyed diving into.

I’ve also worked closely with QA, not just to fix bugs, but to understand how our software was really being used and how we could make everyone’s job easier.

I also became a sort of technical communicator between teams. I genuinely enjoyed sitting in on other teams’ scrums just to hear what they were working on. More than once I’d hear someone describe a problem and immediately think, “Wait… we’ve done that.” Or, “You should talk to Michael or Terry. They’ve already solved something similar.” Other times I’d just say, “Hang on, let me go find the code.”

I’ve always enjoyed making those connections. It never made sense to me for two or more teams to solve the same problem in isolation if I could help connect the dots.

That mindset naturally led me toward reusable libraries, shared packages, internal tooling, and automation. If I could solve a problem once and save five other engineers from solving it again, that felt like a good week.

I’ve mentored engineers, spent countless hours pair programming, translated business conversations into technical work, and occasionally found myself acting as the “skunkworks operator.” When an initiative stalled, a proof of concept needed to be built quickly, or a project needed one more push to get across the finish line, I often found myself in the middle of it.

I also jokingly call myself the “historian.”

After 15 years, I’ve accumulated a lot of context. I can still remember writing code against SharePoint’s server-side object model and building things with Silverlight. I remember that we used to have an old TFS server running on a VM before we eventually migrated to VSTS. I remember why we made the decision at the time to not use Git and instead stick with TFVC.

Those details might not seem important anymore, but they represent something I’ve always valued: understanding where we’ve been and why we made the choices we did. The answer to “Why don’t we do it this way?” is not always that nobody thought of it. Sometimes there was a reason, and that reason is still valid today. Other times it isn’t. But having that history helps us make better decisions.

So what does that make me?

Am I an architect?

A Principal Software Engineer?

A Staff Engineer?

A Platform Engineer?

A DevOps Engineer?

A team lead?

A historian?

The honest answer is… yes. And, I don’t know.

Some days, I think, “Yeah… architect fits.” Other days, Principal feels closer. It seems to depend entirely on whose definition we’re using.

For almost fifteen years, I never really had to think about it. I knew where I fit. I knew what everyone was working on, and because I had been involved in so many different parts of the company, I usually had enough context to point someone in the right direction or jump in myself. If another team needed someone to investigate a new technology, I’d volunteer for the spike. If an initiative stalled, I’d often find myself acting as the “skunkworks operator” to help get it moving again. If I heard a problem during another team’s scrum that sounded familiar, I’d interrupt with, “We’ve already solved that. Let me find the code.”

I loved that role because no two days looked alike, and I genuinely loved what I brought to the table. One day I was deep in Terraform. The next I was helping QA understand a new feature. Then I’d spend an afternoon pair programming with another engineer, only to finish the day sketching out the architecture for a new service. Wearing all of those hats never felt chaotic to me. It felt like exactly where I belonged.

Now I’m part of a much larger engineering organization where responsibilities are naturally more specialized. That’s not a criticism. It has to be that way at this scale. But it has made me realize that the role I loved may not really exist anymore, or at least not in the same form.

When I read job descriptions today, I sometimes see pieces of what I used to do. One company calls it Senior Software Engineer. Another expects it from a Staff Engineer. Another splits it across Platform Engineering, Architecture, DevOps, and Technical Leadership. The titles have changed, the expectations have shifted, and I’m no longer sure where someone like me fits.

Maybe I really am a Cloud Architect. Maybe I’m not.

What I do know is that I’ve never wanted to be the person sitting in an ivory tower drawing diagrams and handing them to someone else. I enjoy understanding the business problem, investigating the unknowns, writing the code, mentoring the engineers, connecting teams, and helping people move forward. I’ve always found more satisfaction in making the entire engineering organization better than I have in owning one particular piece of it.

Maybe that’s still a role. Maybe it isn’t.

All I know is that when someone asks me, “So, Kyle… what do you do?” I still don’t know how to answer that question in a way that feels complete.