When you step into a new leadership role, it's easy to see what you would change.
You identify tools you'd swap out, patterns you'd redraw, edges you'd smooth over.
But you need to pause.
What you are looking at is not just a codebase. It is a system that has adapted over time to ship, to survive incidents, and to work within whatever constraints existed before you arrived.
I learned this the hard way.
Early in my career, I was given responsibility over a system and pushed to clean up rough edges that were slowing work down. The code was ugly, confusing, and offended my architectural sensibilities.
It also turned out to be the only thing keeping a revenue path from collapsing during peak traffic.
I didn't understand the scar tissue yet. I almost tore it open.
Before you optimize anything, understand what you've inherited.
Not just the stack, but the risk profile, the way deployments actually happen, and which parts of the system people trust versus quietly avoid.
Here's how I approach the first 30-60 days.
Start at the production boundary
Start with production, not with languages or frameworks.
Where does it live? Who has access? How does code get there? What happens when something goes wrong? How long does rollback actually take in practice, not in theory?
The most revealing question is simple:
If production is on fire right now, who responds, and how confident are they?
The answer tells you more about maturity than any diagram.
I once asked this in a room and got three different answers. That was the moment I knew the real work was not refactoring code. It was clarifying ownership.
Teams that trust their deployment process move differently from teams that treat every release like a minor crisis.
Trace a real request
Pick something ordinary: a login, a payment, a content update.
Follow it through the system. Which services are involved? Where does it wait? What depends on third parties? Where could it fail? What would happen if one part slowed down or returned bad data?
This is less about judging design quality and more about understanding blast radius.
Architecture diagrams show components. Tracing a request shows pressure points.
Find the irreversible moves
Every system contains decisions that are easy to undo and decisions that are not.
Look for the latter: database schema changes that cannot be rolled back cleanly, long-running migrations, vendor contracts that shape your data model, integrations that only work one way.
Ask how often these changes are made and how they are reviewed.
Mature teams know where irreversibility lives. Less mature teams discover it mid-incident.
Look for hidden coupling
This is the part most leaders underestimate.
Architecture does not just reflect technical decisions. It reflects how the organization is shaped.
I once inherited a system where two teams integrated through a shared adapter layer. It handled data translation and papered over small differences between their services.
Architecturally, it looked reasonable. A clear boundary. A layer meant to keep the two sides decoupled.
The problem was ownership.
Neither team felt responsible for it. When the upstream team changed a field, the adapter failed. When the downstream team needed new data, changes to the adapter required negotiation. Updates meant meetings, and meetings meant someone had to decide who would take the risk if something broke.
Over time, that layer became slow to change. Engineers avoided it unless they had no choice. Bugs lingered because fixing them reopened questions about responsibility. Workarounds accumulated on either side to avoid touching it.
The system kept evolving, just not there.
That was not a system problem. It was an ownership problem encoded in schema design.
You find hidden coupling by watching where work stalls.
Which teams wait on others? Which changes require cross-team sign-off? Where do conversations escalate quickly in Slack? Where does roadmapping feel political instead of technical?
If one team's deploy routinely disrupts another team's roadmap, that is architecture reflecting organizational shape.
You inherit that shape whether you designed it or not.
Audit observability before performance
The instinct for a new leader is to ask about performance.
What is our latency? What is our throughput? Where are we slow?
That instinct makes sense. Performance is visible. It is measurable. It feels like impact.
But performance tuning without visibility is guessing.
The sharper question is this:
How do we know something is broken?
Who sees the alert at 2 a.m.? Which metrics actually change behavior? Which dashboards are opened daily, and which exist to reassure stakeholders?
I've seen teams proudly present performance gains, only to discover later that a critical background job had no alert and had been failing quietly for months. The dashboards looked great. The system was not.
If customers are your primary monitoring system, that is a signal.
Performance comes later. First make sure you can see the system clearly.
Watch a deployment
Ask a developer to ship something while you observe.
Notice how many manual steps are involved. Notice the tone of the explanation. Do they speak confidently, or cautiously? Are there rituals that exist purely to prevent past mistakes?
Deployment friction tells you how quickly the team can learn. If shipping is slow or stressful, feedback loops stretch. When feedback loops stretch, product decisions age before they reach users.
Architecture either compresses learning cycles or expands them.
Read the system's scars
Before you rely only on conversation, read the record.
Look at post-mortems from the last six to twelve months. Read incident logs. Scan Slack threads from real outages.
This is where the system screams at you.
You will see patterns. The same service mentioned repeatedly. The same dependency flaking under load. The same ownership confusion surfacing in different language.
Post-mortems tell you where the system has already failed under stress. They show you which risks are theoretical and which are lived.
Then talk to the people who were there.
Talk to the people who live in it
Understanding architecture is not only analytical. It is conversational.
I sit down with engineers and ask some version of the same question: What is hard here?
The answers are usually understated.
"It works, but it is messy." "That integration was rushed." "We do not fully understand that service." "We have been meaning to clean that up."
Those comments are architectural signals.
Engineers know where the fragile parts are. They know which areas rely on memory rather than documentation. They know which migrations technically succeeded but left scars.
Those are the places most likely to fail.
If they break during your first few months, you do not want to be learning about them for the first time in the middle of an incident.
Listening this way also changes the tone of your leadership. When you ask about fragility without blame, people describe reality instead of presenting a polished version of it.
Polished versions of reality are dangerous.
Make low-regret wins
Understanding does not mean inaction.
In fast-moving environments, waiting too long can create its own risk. The goal is not paralysis. It is sequencing.
Look for low-regret wins. Small, safe improvements that help you learn how the system responds to change without destabilizing anything core.
Fix a flaky test. Remove an unnecessary manual step in deployment. Clarify ownership in one ambiguous area. Clean up something small but painful.
These changes do two things. They build trust with the team, and they teach you how the system reacts when touched.
You learn the mechanics of change before attempting anything structural.
What you are actually evaluating
This is not a code review.
You are assessing change velocity, risk containment, resilience, and the degree to which teams can act independently without destabilizing each other.
The most common mistake new leaders make is trying to optimize what they have not yet understood.
Architecture is not just what runs in production. It is what the team believes is safe to change.
Before you refactor a line of code, understand those boundaries.
That is where the real architecture lives.