The First Ascent

Good design, wrong altitude

I was interviewing for a .NET role at a semiconductor company.

At the whiteboard, I approached the design problem the way I knew how. I moved toward the data model: entities, relationships, and the structure underneath the application.

The feedback was not that the design was bad.

It was that I had started too low.

The better starting point was the real-world domain: the things in it, the responsibilities they carried, how they behaved, and how they interacted. The relational representation should follow from that understanding rather than frame it.

I understood the correction intellectually. I am not sure it had fully landed yet.

Then I got the role.

When the correction became necessary

Soon after joining, I was asked to build a strategy framework in three weeks while moving from Java into an unfamiliar .NET environment.

There was no time to become the strongest person in the new technology before doing the work. I could not solve the problem by leaning harder on implementation knowledge or by beginning with the database and building upward.

The interview correction became practical.

I had to begin with the domain. What were the objects, what did they owe each other, how should they behave — before any of it became tables, services, or code.

That shift sounds obvious to me now. It did not feel obvious then.

I had spent years learning to see structure in data. Now I had to see the system before its storage representation.

The database still mattered. It simply could not lead.

The unfamiliar stack helped more than I understood at the time. It removed the comfort of beginning with what I already knew and forced me to understand the problem at a level less dependent on the technology.

One more level up

Later that year, I went through introductory TOGAF training.

I did not leave the training with a grand theory of architecture. What stayed with me was another change in starting point.

I began forcing myself to create capability views before application architecture.

Before asking which system should do something, I would ask what the business needed to be able to do. Before drawing application interactions, I would try to make the underlying abilities and responsibilities visible.

No one had mandated that sequence.

I was creating the views because different stakeholders needed different ways to see the same problem. Business leaders, process owners, and engineers were not asking the same questions. A single application diagram could not give all of them a useful surface for reasoning.

The capability view sat above the applications. It was more stable than whatever we happened to be building, and wide enough that people arguing from different corners could find themselves in the same picture.

Over time, people began to see me as someone who was good at creating diagrams.

That was understandable. The diagram was the visible artifact.

What I was actually developing was harder to see: the ability to visualize the whole system, move between its levels, and hold the seams together while different stakeholders looked at different parts of it.

The drawing was the output.
The seeing was the skill.

At first, that seeing took deliberate effort. I had to step back, rebuild the shape, and consciously connect the parts. Repetition turned it into muscle memory. Eventually, it became second nature.

AI can draw now. It cannot yet hold the seam.

I don't think I understood that distinction at the time. I'm still working out how much of it I understand now. But the value was never the diagram. It was the judgment underneath—what belonged together, what had to be pulled apart, how one decision changed another domain, and what each person needed to see without losing the whole.

TOGAF gave that instinct more structure. It did not create the instinct, and it was never the point of the story.

Together, the two shifts formed a staircase:

What I did not know yet

I did not leave 2006 thinking I had discovered an architecture method.

There was no clean framework in my head. I was still learning the technology, the organization, and the role. Much of what later became instinct was still deliberate effort.

But a pattern had started.

A problem would arrive in one form, and I'd find myself asking what sat above it. People would argue at the application level, and I'd go looking for the capability view that let them see the same thing. A design would get stuck inside the technology, and I'd climb back to the domain and start again.

None of it felt like method. It felt like a tic I couldn't turn off.

Over time the reframe got faster, until it stopped being a step I took and became the way the problem showed up.

Years later, I would describe architectural vantage as seeing how each partial truth changes the whole. I did not have that language in 2006.

I only knew that different people needed different views, and that someone had to keep those views connected.

The habit came before the name.