Back to all posts
The Role That Doesn't Have a Title
Insights 4 min read

The Role That Doesn't Have a Title

After 25 years bridging strategy to production, I still can't answer 'what do you do?' cleanly. That might be the point.

Career Leadership Strategy Personal Growth
NC

Nino Chavez

Principal Consultant & Enterprise Architect

Someone asked me recently what my ideal role would be.

It’s a reasonable question. I’ve been in this industry for 25 years. I’ve held titles—Enterprise Architect, Managing Delivery Architect, Domain Architect, Strategic Advisor. I’ve led $10M programs with 100+ people. I’ve also written production code this week.

And I still don’t have a clean answer.

The Problem with Titles

Traditional role titles assume you stop at a boundary:

  • Strategist → hands off to designers
  • Designer → hands off to engineers
  • Engineer → hands off to ops
  • Consultant → hands off to implementers

The titles exist because organizations are structured around handoffs. Someone owns strategy. Someone else owns design. Someone else owns build. Someone else owns production.

The problem is that most programs fail in the handoffs.

Intent gets lost. Context evaporates. The thing that ships doesn’t match the thing that was planned. Not because anyone did their job poorly—but because no one’s job was to carry context across the transitions.

What I Actually Do

My value is in the transitions:

Strategy → Design: Making sure the business intent survives contact with technical constraints.

Design → Build: Making sure the architecture actually gets implemented as designed, not as interpreted.

Build → Production: Making sure what works in dev works under load, at scale, with real users.

Production → Performance: Making sure shipped doesn’t mean finished—that we learn, iterate, and improve.

Most of my career has been preventing the drift that happens at each of these boundaries. I’m the person who notices when the strategy deck doesn’t match the technical spec. When the architecture diagram doesn’t match the code. When the demo doesn’t match production.

That’s not a title. It’s a function.

Why This Is Hard to Explain

When someone asks “what do you do?”, they’re asking for a category. Strategist. Architect. Engineer. Consultant.

But my category is the seams between categories. The transitions. The handoffs. The places where signal gets lost.

This is genuinely difficult to title because:

  1. It’s not a specialty. I’m not the world’s best strategist, or the world’s best architect, or the world’s best engineer. I’m the person who can operate across all of them well enough to catch the drift.

  2. It requires range. To bridge strategy and engineering, you have to speak both languages fluently. Most people specialize. Specialists don’t bridge.

  3. It’s invisible when it works. If I do my job well, the program just… works. The strategy becomes the product. The architecture becomes the code. There’s no dramatic rescue, no heroic intervention. Just execution that matches intent.

  4. It doesn’t scale through delegation. You can’t hire 10 people to “carry context.” It’s not a team function. It’s a specific kind of attention.

The AI Angle

The last two years have made this both easier and harder to explain.

Easier, because AI-assisted development has given me concrete evidence. I can point to a project where I built a $2.5M-equivalent platform in 80 hours. The 48-64x productivity multiplier is documented. The receipts exist.

Harder, because now everyone claims to “do AI.” The signal-to-noise ratio on AI expertise is terrible. Half the market is selling strategy decks about AI. The other half is vibe-coding prototypes that will never see production.

I’m neither. I’m shipping production systems with AI assistance, and I’m documenting what actually works versus what sounds good in a pitch.

What I’d Tell Someone Hiring

If you’re looking for someone to fill a box on an org chart, I’m probably not your person. The box doesn’t exist.

If you’re looking for someone to own the outcome—from “here’s what we need to accomplish” through “it’s in production and performing”—that’s the job I actually do.

The title can be whatever makes your HR system happy. The work is preventing drift.

The Honest Answer

When someone asks what my ideal role is, the honest answer is:

The role where my job is to carry context across the transitions that usually break programs. Where I’m accountable for the outcome, not just my slice of the process. Where “no handoffs” is the job description.

That role doesn’t have a standard title. Maybe it doesn’t need one.


Related: Signal in the Noise: My Personal Philosophy and Intent-Driven Engineering: By The Numbers

Share:

More in Insights