Moving from Engineer to Architect: The Skills That Matter

A customer called with a simple question: "How long does it take for my IoT message to get processed?"

We had no answer.

Azure IoT Hub was processing millions of messages per day. Stream Analytics was handling the data. Everything worked fine. But there was no way to measure end-to-end processing time. No timestamps. No tracking. No visibility.

The customer needed this data to optimize their manufacturing process. An engineer might build a custom solution for that one customer. Add some logging. Create a dashboard. Ship it and move on.

But this wasn't just one customer's problem. Thousands of customers were running IoT workloads blind. They had no idea if their messages took 10 milliseconds or 10 seconds to process.

I collaborated with the product team to integrate standard message property bags into IoT Hub. Now, every customer can track message processing time. One question revealed a gap that affected the entire platform.

That's the difference between engineering and architecture. Engineers solve the problem in front of them. Architects solve a class of problems. Engineers make code work. Architects think about what happens when that code scales, fails, or succeeds beyond expectations.

The Scope Shift: From Local to Global

Transitioning from engineer to architect involves expanding your scope in three key ways. Each shift changes how you approach problems.

Time Scope: Years, Not Sprints

Engineers work in sprints and releases. You build features, fix bugs, and ship code. Your timeline is measured in weeks or months.

Architects think in years. You design systems that will evolve, scale, and adapt long after you've moved on to other projects. This longer timeline changes how you make decisions.

When I was building components for the Azure Terraform provider, I wasn't just solving today's deployment problems; I was also laying the groundwork for future solutions. I was creating patterns that thousands of customers would use for years to come. Every design choice had to consider future needs, changing requirements, and unknown use cases.

This longer timeline means you can't just build what's asked. You have to build what will be needed.

Blast Radius Scope: Understanding Cascading Failures

Here's a disaster story that illustrates why blast radius thinking is crucial. A major auto manufacturer had an application that worked perfectly with 200,000 connected vehicles. When they scaled to 2.5 million vehicles, one component failed, and every single vehicle went offline.

Engineers focus on their component working correctly. Architects think about what happens when any component fails.

In that auto manufacturer's system, each service was built correctly. But when one authentication service went down, it created a cascading failure that took out everything else. The engineers constructed resilient individual components. However, no architect was considering the failure patterns across the entire system.

After that incident, I redesigned the architecture with scale units and credential caching. We broke the single point of failure that could bring down millions of vehicles. It wasn't about better code. It was about better systems thinking.

This is the mental shift that matters most. Start asking: "If this component fails, what else breaks?" Then design to contain that blast radius.

People Scope: Beyond Development Teams

Engineers primarily work with other engineers. You coordinate with your team, as well as a few adjacent teams. Your interfaces are APIs and code reviews.

Architects work with everyone who touches the system. Operations teams who will maintain it. Support teams who will troubleshoot it. Business teams who will depend on it. Customers who will use it.

When I led the mentorship program for over 400 Azure Cloud Solution Architects, I learned that technical skills alone weren't enough. The best architects could translate between different groups. They understood that a good technical solution that operations couldn't maintain was a failed solution.

This shift changes how you design systems. You're not just building for performance or maintainability. You're building for the humans who will work with your system.

Stay Close to the Code

Here's the trap that kills many architects: you stop writing code.

You get promoted. You have more meetings. You spend time on strategy and design documents. Before you know it, you haven't written meaningful code in months.

This is a disaster. Architects who don't code become ivory tower architects. They design systems that appear well-planned on paper but often fail in practice. They lose credibility with engineers. Worse, they lose touch with reality.

I've seen architects recommend patterns they've never built. They'll suggest "just use microservices" without understanding how hard they are to run. Or they'll design clean APIs that are impossible to test or deploy.

The best architects stay hands-on. When I built the RAG system that reduced action item creation from 4 hours to 5 minutes, I wrote the code. When I created custom Kubernetes resource providers for storage testing, I implemented them myself.

This isn't about proving you can still code. It's about staying grounded in reality.

Code Keeps You Honest

When you build your own designs, you find their flaws quickly. That clean abstraction becomes hard to work with when you try to test it. The simple API becomes confusing when you attempt to document it.

Code forces you to think through edge cases that look simple on architecture diagrams. How do you handle timeouts? What happens during deployment? How do you debug problems in production?

These aren't theoretical questions when you're writing the implementation.

Code Keeps You Current

Technology changes fast. New tools, new patterns, new constraints. If you're not writing code, you're not learning how these changes affect real systems.

After we solved the IoT message processing problem, the next question was obvious: how do we test this? You can't just assume your system handles failures well. You need to prove it.

This led to chaos engineering experiments, where deliberately breaking things was used to see what happens. The concepts we developed eventually became part of what Microsoft built into Azure Chaos Studio.

But I only learned this by building the tests myself. Reading about chaos engineering wasn't enough. I had to write code that broke services and see how they reacted.

This hands-on work shaped how I think about resilience. It couldn't have come from documents or meetings.

Code Keeps You Credible

Engineers can spot architects who don't code. They ask detailed questions about implementation. They push back on designs that seem impractical. If you can't answer with confidence, you lose their trust.

But when you can discuss the implementation details, when you can explain the tradeoffs you made while building it, engineers listen. They know you understand their constraints because you've lived them.

This credibility is essential. Architecture happens through influence, not authority. If engineers don't trust your technical judgment, your designs won't get implemented properly.

How to Stay Hands-On

You don't need to write production code every day. But you need to write meaningful code regularly. Here's what works:

Build prototypes. When you design a new pattern, build a working prototype. This proves the design works and reveals problems early.

Write tools. Build internal tools that solve real problems. Automation scripts, monitoring dashboards, and deployment utilities. These don't require product-level code quality, but they solve real problems.

Contribute to open source. Pick projects related to your work and contribute. This keeps you current with development practices and community patterns.

Take on small features. When your team needs a minor feature implemented, do it yourself. Don't take the critical path items, but handle the smaller pieces.

Code during architecture reviews. When reviewing designs, write small implementations to test your assumptions. Can you easily implement this API? Is this deployment pattern as simple as it looks?

The goal isn't to be the best coder on your team. It's to stay connected to the reality of implementation. Your designs will be better, your credibility will be higher, and your influence will be more effective.

Making the Mental Transition

The shift from engineer to architect is mental, not technical. Here's how to start thinking differently:

Stop optimizing locally. Engineers optimize their component. Architects improve the whole system. This means sometimes your component performs worse, so the system performs better. It feels wrong at first, but it's the right thing to do.

Think in failure modes. Engineers think about the happy path. Architects think about everything that can go wrong. Start every design discussion with "What happens if this fails?" Then design systems that gracefully handle those failures.

Design for operations. The best code is useless if operations can't maintain it. Build monitoring, logging, and troubleshooting into your systems from the start. Make them easy to observe and debug.

Focus on interfaces. Engineers focus on how things work inside. Architects focus on how systems connect. Clean interfaces conceal complexity and enable teams to work independently. Spend more time designing how systems connect than how they work internally.

Plan for success. Engineers build to requirements. Architects build for growth. What happens if your system gets 10x more traffic? What if it becomes business-critical? Plan for success, not just the minimum that works.

From Individual Contributor to Team Enabler

The hardest part of becoming an architect is realizing your impact comes through other people. As an engineer, you ship code. As an architect, you enable others to build better systems.

This means your skills shift from writing code to influencing decisions. You need to communicate technical concepts to non-technical stakeholders. You need to build consensus around design decisions. You need to coach other engineers on architectural thinking.

When I managed a 15-person Cloud Solutions team across Fortune 100 engagements, my job wasn't to write the best code. It was to make sure every engineer on my team could think architecturally about their piece of the system.

Your value becomes your ability to see the big picture and help others see it too.

The Skills That Actually Matter

Technical skills matter, but they're not what makes the difference. Here are the skills that separate good architects from great ones:

Thinking about systems. The ability to understand how parts interact and influence one another. This isn't about specific technologies. It's about understanding patterns and relationships.

Communication. You need to explain complex technical concepts to different audiences. The same design needs to make sense to engineers, operations teams, and business stakeholders.

Making decisions with incomplete information. Architects make decisions without knowing everything. You can't wait for perfect requirements or complete understanding. You need to make good decisions quickly and adjust as you learn more.

Getting things done through influence. Most architectural work occurs through influence, rather than direct control. You need to convince people to adopt better patterns and make better decisions.

Start Thinking Architecturally Today

You don't need a new title to start thinking like an architect. Here are questions that will shift your perspective:

What happens to my system under 10x load? What about 100x?

If any component in my system fails, what else breaks?

How will the operations team troubleshoot problems in production?

What would this system look like if it became business-critical?

How does my design enable or constrain future requirements?

Who else could benefit from the capabilities I'm building?

Start asking these questions about every system you touch. The answers will change how you build software.

The transition from engineer to architect isn't about learning new tools; it's about embracing a new perspective. It's about expanding your scope and thinking about the global impact of your technical decisions. It's about building systems that work not just today, but for years to come. It's about enabling others to build better solutions on top of what you create.

That's the difference between making code work and building systems that matter.