The VP of Engineering Runs the GCC. But That Does Not Mean Architecture Is Being Done.

The Role Looks Powerful

At a GCC, the VP Engineering or Director of Engineering is one of the most powerful roles. He manages engineering teams. He owns delivery capacity. He tracks sprint velocity, release progress, code quality, cloud execution, platform stability, DevOps maturity, production incidents, and engineering productivity.

From HQ, this looks like control. So a quiet assumption forms..if the VP Engineering is strong, architecture must be strong. That assumption is wrong.

The Civil Construction Equivalent

A VP Engineering at a GCC is not equivalent to the architect of a 50-storey building. He is closer to the construction director, site engineering head, or delivery head. He may manage hundreds of engineers. He may control construction speed. He may ensure quality. He may manage contractors. He may coordinate material usage. He may reduce defects. He may improve execution productivity. He may ensure the building is completed on time.

But that does not mean he defined the architecture of the building.

In civil construction, no one says:

The construction director delivered 50 floors, therefore he designed the building.

But in software, we say:

The VP Engineering delivered 50 systems, therefore architecture is covered. That is the distortion.

What the Architect Defines

In a 50-storey building, the architect or design authority defines what the building is meant to be. Is it residential, commercial, or mixed-use? How are the floors organized? How do people move through the building? Where are lifts, staircases, service shafts, utilities, safety exits, and functional zones placed? How does the load move from the top floors to the foundation? How does the building behave under wind, load, usage, fire, evacuation, and long-term operation?

That is design authority. That is not construction management. Only after this is defined does construction begin. Then the construction director manages concrete, steel, workers, cranes, contractors, schedules, quality checks, defects, and handover.

Both roles are important. But they are not the same role.

The Software Equivalent

In software terms, the architect must define P1–P4 before P5 begins.

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

P2: Process defines the sequence of activities and decisions required to realize that strategy.

P3: Systems / Logic defines the systems and sub-system logic that execute or enforce the business flow across rules, functions, data, UI, access, timing, and interactions.

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

Only after this does P5 begin.

P5: Implementation Tasks is where people and IT teams build, modify, configure, and deploy components.

P6: Operations is where people and IT operations run, monitor, maintain, and stabilize the service.

The VP Engineering role is mainly P5, with some P6. He builds and stabilizes.

He does not, by default, define P1–P4.

Where the Mistake Happens

The VP Engineering can build faster. He can deploy more engineers. He can improve velocity. He can reduce defects. He can improve DevOps maturity. He can stabilize production. He can improve platform reliability. He can control engineering cost.

But if the project anatomy is incomplete, his execution strength cannot fix it.

1. If floor usage is unclear, construction speed will not solve it.

2. If lift placement is wrong, more workers will not solve it.

3. If utilities are badly planned, better concrete will not solve it.

4. If load flow is not properly designed, faster execution will only build the wrong thing faster.

The same thing happens in software. If P1–P4 are not explicit, the VP Engineering is only scaling construction. He is not defining architecture.

Bank Lending Example

Take a bank lending project. The VP Engineering organizes teams around services.

Eligibility service. Risk scoring service. Pricing service. Document verification service. Approval service. Disbursement service. Collections service.

The teams are staffed. The JIRA boards are moving. The APIs are being built. The releases are planned. The cloud environments are ready.

From GCC leadership, the project looks healthy. But the real lending decision may still be undefined.

1. What outcome must the lending project achieve?

2. What sequence should the lending decision follow from application intake to eligibility, risk scoring, pricing, approval, documentation, disbursement, servicing, and collections? How should eligibility logic interact with risk scoring?

3. How should risk scoring affect pricing? How should policy exceptions affect approval? How should documentation status control disbursement?

4. How should regulatory traceability be enforced?

If these are not defined before coding begins, engineering will still deliver. But it will deliver partial assumptions.

What Happens Inside the Project

Each team builds its service. Each service works. Each API responds. Each release passes testing.But the lending decision still breaks.

Eligibility behaves differently across channels. Risk scoring qualifies a borrower, but pricing gives the wrong offer. Approval logic does not properly account for policy exceptions. Disbursement waits on documentation conditions that were never explicitly connected. Collections logic does not reflect the original risk and pricing assumptions.

Every team delivered.

But the project did not gain decision clarity.

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, more on delivery capacity, and more on governance meetings.

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.

What HQ Gets Wrong

HQ often treats the VP Engineering as the safest architecture bet because the role has scale. Large teams report to him. Large budgets sit under him. Large platforms are delivered by him.

But scale of engineering responsibility is not the same as architecture responsibility. A VP Engineering can own 500 engineers and still not own P1–P4.

He can deliver 50 systems and still not define how the project must behave. He can run a world-class GCC and still be operating mainly in P5 and P6.

The Real Correction

The correction is not to weaken the VP Engineering role. The correction is to stop confusing engineering leadership with architecture.

Before engineering execution scales, P1–P4 must be explicit.

1. What outcome must this project achieve?

2. What decision sequence must it follow?

3. What system and sub-system logic must govern the decision? What components must exist before coding begins?

Only then does P5 implementation have meaning. Only then does P6 operations have substance. Only then does engineering velocity produce value instead of multiplying hidden assumptions.

Diagnostics note

The VP Engineering is critical. But he is not automatically the architect.

At the GCC, engineering leadership can build faster, scale teams, improve platforms, and deliver releases. But if P1–P4 are not explicit, the GCC is only scaling implementation.

Not architecture.

The missing work is not more engineering leadership. The missing work is explicit project anatomy. One Enterprise. One Anatomy.