Ascend Before You Descend

Why stepping back is hard

The first time someone tells you to step back and look at the whole, the advice sounds simple.

Doing it consistently is not.

For a long time, I had to interrupt myself. A request would arrive, and my instinct was still to solve it at the level where it had been handed to me. Sometimes I would finish a discussion, only to realize later that I had answered the question exactly as asked without examining whether it had been framed at the right level.

The reframe was not yet instinct. It was an extra step I had to remember to take.

That awkward stage matters because it is where most engineers who want to grow actually are.

They understand the idea of climbing. Under pressure, they still descend too fast.

The climb is how that changes.

Not through one framework. Not through a title. Through repeated practice, sustained long enough that moving between levels stops feeling like a technique and starts becoming how the problem appears.

The climb is made of reps

Early architectural growth can feel strangely artificial.

You have to force questions that do not yet arise naturally:

• What business outcome sits above this request?
• What capability is the system trying to provide?
• What domain owns the behavior?
• What changes outside the boundary of this task?
• Who needs a different view of the same problem?

At first, asking those questions slows you down. That can be uncomfortable, especially when the organization rewards visible movement and the task already looks clear.

There is a second kind of friction, and it is structural. Product may own the ask, business may own the framing, and a more junior engineer who sees that the real problem is upstream of the ticket can still be waved back into their lane — not because the observation is wrong, but because in many organizations the person who can see the problem and the person allowed to name it are not the same person. If that has happened to you, it is not a sign the instinct was wrong. It is a sign you were early. The way through is not to argue for ownership; it is to make the ambiguity visible and discussable — exactly the muscle Drill 4 is designed to build.

The temptation is to believe that good architects simply see more.

What I found was less mysterious. They have usually practiced the reframe more times.

The early reps are conscious. You stop, move upward, redraw the problem, and descend again. Sometimes the reframe adds nothing. Sometimes it reveals that the requested feature is only the visible edge of a different problem. Either way, the repetition matters.

After enough reps, the pause gets shorter.

After enough years, it can disappear almost entirely.

I should be honest about the order this happened in. I didn't climb by skipping the technology. I went deep, fast — deep enough to be trusted with the hard problems — and the altitude came from having stood at the bottom, not from floating above it. The engineers who ascend well are usually the ones who could still do the work below them.

Altitude without that depth is just distance.

What the climb looks like over time

The timeline is different for everyone, but the progression tends to have a recognizable shape.

In the first six months: the reframe feels forced

You are still learning to resist the task as given.

You may need to write the levels down explicitly. You may ask questions that feel clumsy. You may move too high and lose the room, or stay too low and recognize it only afterward.

This stage is less about producing better architecture than about noticing your own starting point.

A useful sign of progress is not that you always find the deeper issue. It is that you begin catching yourself before implementation has already narrowed the decision.

Through the next year or two: translation becomes the work

You start noticing that the same problem must be expressed differently for different audiences.

A business leader may need to understand the outcome and operating impact. Product may need the user and capability implications. Engineering may need boundaries, contracts, data ownership, and risk.

Each audience needs a different view of the same underlying truth.

This is where many engineers first discover that communication is not separate from architecture. Creating the right view is part of forming the decision.

You also begin to recognize when teams are disagreeing because they are reasoning at different levels. One person is discussing a workflow, another an application, another a business policy. All may be correct inside their own frame.

The practice is learning to reconnect those frames before the disagreement hardens into design.

After several years: patterns begin arriving before explanations

Repeated exposure changes what you notice.

You begin to recognize familiar shapes:

• a reporting request that is beginning to distort a transactional model
• an integration request hiding an ownership problem
• an application enhancement compensating for a missing domain concept
• a local optimization transferring complexity into another team
• a tactical bridge quietly becoming the permanent extension point

The value is not that you have seen the exact problem before. Usually you have not.

The value is that you have seen enough related shapes to know where to look.

By then, moving upward and downward may feel less like a sequence of steps. You still need to verify your judgment, but the structure starts appearing earlier.

That is when practice is becoming perception.

A training regimen for building altitude

These are not steps to run once. They are drills.

Use them repeatedly across different kinds of work. The variety matters. A single domain can build depth, but different contexts teach you which parts of your mental model are durable and which were only local habits.

01Rewrite one ticket at five altitudes

Once a week, take a real ticket or enhancement request and restate it as:

1. Implementation — What change has been requested?
2. User need — What is the user trying to accomplish?
3. Business outcome — What result is the organization seeking?
4. Required capability — What must the business or system be able to do?
5. Architectural implication — What concept, boundary, ownership decision, or dependency might this affect?

Do not assume every rewrite will uncover a strategic issue. The purpose is to practice movement across levels without losing the connection between them.

Over time, compare your versions. Notice where you tend to stop. Some engineers stay close to implementation. Others ascend easily but struggle to return with something buildable.

The drill trains both directions.

02Explain the same problem to three audiences

Choose one active problem and explain it separately to business, product, and engineering.

Do not merely simplify or add technical detail. Ask what each audience needs in order to make a sound decision.

Then compare the three explanations:

• Did the underlying problem remain consistent?
• Did you accidentally change the meaning to fit the audience?
• Did one view expose a gap the others hid?
• Can the views be connected on one shared map?

Repeat this until changing altitude no longer feels like changing the subject.

03Trace one local decision outward

For one design decision each week, follow its effects beyond the immediate component.

Trace it into:

• adjacent domains
• data ownership
• operating workflows
• reporting and analytics
• security and access
• future product options
• another team’s delivery burden

You are not trying to produce exhaustive impact analysis for every decision.

You are training yourself to notice where complexity moves when it leaves your component.

A local solution can be technically clean and still make the wider system worse. This drill teaches you to see transferred complexity before it becomes someone else’s surprise.

04Take on work whose boundary is not already defined

Tickets teach execution inside a frame. Architectural growth requires some exposure to forming the frame.

Look for problems where:

• the owner is unclear
• several systems are involved
• teams use the same term differently
• the requested solution is already prescribed
• nobody can explain why the current process keeps producing exceptions

You do not need formal authority over the problem. Start by creating a view that makes the ambiguity discussable.

You are there to make the ambiguity discussable, not to seize ownership. The practice is turning an unshaped space into a shared surface for reasoning.

05Revisit a past tactical solution

Once a month, choose a change that was delivered successfully but left behind friction, workarounds, or debt.

Go back to the immediate need it solved, then look for the strategic question underneath it. Name the concept or boundary that remained unresolved. Ask what made the tactical path reasonable at the time, and what would have made the bridge easier to exit.

Do this without blaming the earlier team. Most tactical decisions make sense inside the pressure and information available at the time. The practice is learning to see what the implementation could not resolve.

Retrospective practice sharpens future judgment.

Keep a record of the climb

Growth is difficult to see while it is happening.

Keep a lightweight record of your reframes: the original request, the level at which it arrived, the higher-level question you found, and what changed because you asked it.

Do not turn this into documentation overhead. A few sentences are enough.

Review the record every few months.

You may notice that your questions are changing before your answers are. You may see that you are finding ownership problems earlier, translating between audiences more easily, or recognizing when a feature request is carrying several business meanings.

Those are signs of altitude developing.

They are usually visible in hindsight before they are visible in the moment.

When the reps become perception

The most noticeable change is not that ambiguity disappears.

It is that ambiguity becomes less paralyzing.

You become more comfortable separating what is known from what still needs shape. You stop needing the entire solution before forming the next useful view. A map can be incomplete and still create alignment.

The shifts start showing up in how you read the problem:

• A prescribed solution stops looking like the problem itself and becomes one possible answer.
• A technical constraint stops defining the system and becomes something you locate within it.
• An incomplete map stops feeling like failure and becomes enough to create alignment.
• The first framing stops feeling fixed; you become less attached to it.

Two people can look at the same diagram and see different things. One sees boxes and arrows. You see where a boundary is under strain and where a change may travel next. That difference is not in the diagram. It is in the climb.

Altitude is not valuable if it leaves you above the work. The practice must eventually improve implementation — clearer boundaries, better sequencing, fewer accidental couplings, decisions that stay coherent when details change.

And these shifts accumulate. Each rep leaves a little more of the shape behind — until you are no longer assembling the view each time. You are carrying it.

The map accumulates

There is another thing the reps build that I did not recognize at first: a map.

Not a diagram — a working mental model of how the enterprise operates.

Every time you go deep into one area, you learn how a system actually behaves, where the data comes from, which process owns a decision, and where the exceptions live. Every time you step back, you connect that detail to something broader — another capability, another process, another domain.

Over time those fragments begin connecting. You are no longer seeing isolated systems. You are carrying an increasingly coherent model of how the whole thing operates.

The map is not invented from above. It accumulates through going deep, and connects through stepping back. Stay only high and the map is theoretical. Stay only low and you collect detail without seeing how the pieces belong together.

Eventually you carry enough of the shape that when a new request arrives, you can see where it lands — and what else it is likely to disturb.

What the climb finally builds

There is one more thing the climb teaches: how to enter an unfamiliar area without pretending it is familiar.

Depth and abstraction are not alternatives. They do different jobs.

Technical depth gives you something real to compare against. Abstraction lets you hold the unknown long enough to make that comparison useful.

When I move into a new area, I rarely start from zero. I look for the shape I already understand, then ask where the new thing behaves differently. That is how a shift from one programming paradigm to another becomes manageable: the concepts may be new in practice, but you can anchor them against what you already know while the hands-on depth catches up.

Over time, that comparison becomes its own skill. The more varied your foundation, the more reference points you have. You stay calmer because the unfamiliar stops looking like a blank wall; it becomes a set of differences to understand.

The opposite failure is common too.

The transferable capability comes from the interlock: enough depth to learn fast, and enough abstraction to keep moving while you learn.

There's a reward at the top of this that's worth naming. When the depth is real, you can sit in any seat on a hard program and be trusted there — work through implementation with the engineers, step back with the architects to test the shape, and still stay in the outcome conversation with the business. None of those levels is opaque to you.

That's what altitude built on depth actually buys: not a higher title, but the ability to stand at any level of the problem and be right. You earn that seat by seat, from the bottom up.

The limit: do not make every problem architectural

There is a failure mode on the other side.

Once engineers learn to ascend, some begin pulling every task upward. Small changes become capability discussions. Local defects become domain redesigns. The framework becomes more important than the outcome.

That is not architectural maturity. It is abstraction without judgment.

And there's a floor as well as a ceiling. You don't earn the right to ascend until you've earned the depth to descend. Altitude claimed without that depth is the thing engineers rightly distrust.

Some problems are genuinely small.

A contained, reversible change with clear ownership and no meaningful effect outside its boundary may deserve a direct solution. A bug may simply be a bug. A field may simply be a field.

The goal is not to maximize altitude.

The goal is to reach the level where the decision can be made coherently, and no higher than the problem requires.

Sometimes that level is the code.

Knowing when not to ascend is part of the climb.

A cadence to begin with

For the next three months:

• Weekly: Rewrite one ticket at five altitudes.
• Weekly: Trace one local decision across at least one seam.
• Per meaningful problem: Explain it separately to business, product, and engineering.
• Monthly: Revisit one tactical solution and name the strategic question underneath it.
• Quarterly: Review your notes and identify what you now notice earlier than you did before.

Then repeat.

The exercises are simple. The development is not.

For a while, the reframe will feel slow and self-conscious. You will sometimes ascend and find nothing useful. You will sometimes recognize the real question only after the implementation has begun.

Keep practicing.

The descent is where the work becomes visible.

The ascent is what changes the quality of everything that follows.