I Am the Chief Code Supervisor. But I’m Called the Chief Architect of the Project.

The Title Looks Powerful

My title says Chief Architect. Inside the project, people look to me for architectural decisions.

I review code structure. I guide microservices design. I approve API patterns. I check service boundaries. I comment on deployment design. I question performance choices. I guide refactoring. I review cloud patterns, DevOps pipelines, logging, monitoring, and release readiness.

This is important work. But structurally, I am supervising implementation (coding). I am the chief code supervisor. Not necessarily the architect of the project.

Where I Actually Operate

Inside the project, I operate mainly in P5: Implementation Tasks and partly in P6: Operations.

P5: Implementation Tasks means the people and IT tasks that build, modify, configure, or deploy components.

P6: Operations means the business and service operations by people, and IT operations that run, monitor, and maintain the service.

That is where most of my work sits. I help teams build better. I help systems run better. I help delivery move with fewer defects. But this does not automatically mean I have defined the architecture of the project.

What I Am Not Defining

Before coding begins, the project must have explicit P1–P4.

P1: Strategy is the direction and value outcomes the project must achieve.

P2: Process is the sequence of activities required to realize the strategy.

P3: Systems / Logic is the system and sub-system logic that executes or enforces the business flow — including data, rules, functions, access, UI, timing, and interaction logic.

P4: Component Specifications are the parts that make the systems real — data, functions, rules, events, interfaces, UI, network, and other component specifications.

If I am not defining these, I am not defining the project architecture. I am supervising how P5 implementation happens after architecture (P1-P4) should already have been defined.

The Civil Construction Equivalent

In civil construction, this is like calling the construction supervisor the architect of a 50-storey building. The construction supervisor may control workers, schedules, concrete pouring, steel fixing, quality checks, vendor coordination, defects, and handover.

That role is critical.

But no one says: The person supervising concrete, steel, and site execution is the architect.

The architect defines what the building is meant to be, how floors are organized, how people move, how lifts and staircases are placed, how utilities flow, how load transfers, and how the building behaves as a whole. Only after that does construction begin.

In software, we have blurred this distinction. Because I supervise code, we call me Chief Architect. That is the distortion.

Bank Lending Example

Take a bank lending project. I guide teams to create:

eligibility service, risk scoring service, pricing service, document verification service, approval service, disbursement service, collections service.

I review whether the services are modular. I check whether APIs are clean. I ensure deployment is scalable. I push teams to improve code quality.

From a delivery view, I look like the Chief Architect.

But the real question is different.

1. What lending outcome must this project achieve?

2. What exact decision sequence must happen from application intake to eligibility, risk scoring, pricing, approval, documentation, disbursement, servicing, and collections?

3. How should eligibility logic interact with risk scoring?

4. How should risk scoring affect pricing?

5. How should policy exceptions affect approval?

6. How should documentation status control disbursement?

7. How should regulatory traceability be enforced?

If these are not explicitly defined before coding begins, then I am not architecting the lending project. I am supervising code that implements partial understanding.

What Happens in the Project

Each service gets built. Each API works. Each sprint closes. Each release moves forward.

But the lending decision still behaves inconsistently.

1. Eligibility works in one channel and fails in another.

2. Risk scoring qualifies a borrower, but pricing gives the wrong offer.

3. Approval logic does not properly handle policy exceptions.

4. Disbursement waits because documentation conditions were never explicitly connected.

5. Collections logic does not reflect the original risk and pricing assumptions.

Every team delivered. But the project anatomy was never defined.

Financial Impact

This becomes expensive. Every change requires rediscovery. Impact analysis depends on senior engineers. Testing expands across services. Rework increases. Manual exceptions continue.

Business teams lose time reconciling system behavior. The bank spends more on coordination, more on change, more on defect correction, and more on delivery capacity.

Revenue leakage appears through delayed approvals, missed offers, incorrect pricing, and lost lending opportunities.

Margins reduce because exceptions, discounts, manual handling, and rework absorb value.

The project becomes more expensive without becoming more precise.

Why the Title Becomes Dangerous

The danger is not that I review code. The danger is that the organization believes architecture is covered because I review code.

So P1–P4 remain implicit. Nobody stops the project and asks:

1. Has the outcome been defined?

2. Has the decision sequence been defined?

3. Has the system and sub-system logic been defined?

4. Have the component specifications been defined before coding begins?

Instead, the project moves forward because the Chief Architect is reviewing implementation. That is how code supervision gets mistaken for architecture.

The Real Correction

If I am truly the Chief Architect of the project, I must define P1–P4 before P5 begins.

I must define what the project must achieve.

I must define how the decision flow works.

I must define how rules, functions, data, UI, timing, and interactions behave together.

I must define the components required before teams start building services.

Only then does my review of code, APIs, microservices, and deployment have architectural meaning.

Diagnostics note

I review code. I guide implementation. I supervise service design. I improve delivery quality. This is important.

But if P1–P4 are not explicit, I am not the Chief Architect of the project. I am the Chief Code Supervisor.

And calling that architecture is how projects get delivered without being properly defined. One Software Platform, One Anatomy.