The New Definition of “Engineering Excellence”: A Message to Today’s Leaders

Let me be direct:  Please do not keep calling yourselves as engineering leaders if all you do is track velocity, chase SLAs, and manage escalations.

Somewhere along the way, many of us became:

• PPT experts
• Excel trackers
• Meeting coordinators
• Escalation managers
• Delivery cops
• Talkietects (only talk with buzz words, drawing boxes and flows on the board.. with No Fundamental Technical Knowledge.. )

But not engineering leaders.

And the truth is uncomfortable: Velocity and SLA are lagging indicators of good engineering. They tell you what happened, not why it happened.

If we want real engineering excellence, we need to redefine it, honestly.

Here is what today’s engineering excellence actually looks like:

Excellence Is Not How Fast You Deliver. It’s How Reliably You Deliver.

Velocity without quality = debt.

SLA without stability = firefighting.

Real engineering excellence = fewer incidents + predictable releases + lower rework + cleaner architecture

If your team is fast but breaking production every month, that is not excellence, that is reckless.

If You are Not Investing in Engineering Hygiene, means You are Not Leading Engineering

Ask yourself: When was the last time you reviewed:

• CI/CD health
• Deployment reliability
• Code review quality
• Observability
• Test coverage
• Architecture evolution

If your answer is “I don’t have time”, that is the problem. Leadership drifted into operations.

Engineers don’t grow if leaders don’t push engineering discipline.

Stop Measuring Output. Start Measuring Predictability.

Anyone can ship fast once. Excellence is the ability to ship fast every time.

New metrics: Cycle time, MTTR, Deployment frequency, Change failure rate, Rework percentage, Debt burn-down, Automation coverage

If these are not in your dashboard, you are not measuring engineering.

Engineering Excellence Requires Saying "NO"

No to shortcuts, No to temporary work-arounds, No to “just deploy it.” , No to timelines that ignore architecture.

If everything is “urgent,” then nothing is excellent.

Your team needs clarity and boundaries, not a Jira checklist.

Leaders Must Be Technically Curious Again (and always)

You don’t need to code. But you must understand what is possible.

If your engineers know more about modern patterns, Ai-generated code workflows, testing automation, or cloud architecture than you do, you can't challenge them, guide them, or protect them.

Leadership cannot be Excel-driven or PPT-driven in an engineering-first world.

Engineering Excellence = Strong Foundations, Not Fancy Features

The boring things matter:

• Logging
• Monitoring
• Alerts
• Modular code
• Documentation
• Test automation
• Versioning

If these are weak, everything else collapses, no matter how many features you shipped.

Your Culture Is Either Engineering-First or Escalation-First

Strong teams: review code seriously, invest in design upfront, automate everything, document decisions, fix debt continuously.

Weak teams: chase tickets, patch problems, skip tests, rush releases, fear deployment days

Engineering Culture is leadership’s responsibility, not the team’s responsibility

Engineering Excellence Is a Leadership Discipline, Not a Developer Skill

If leaders don’t champion:

• Good architecture
• Clean code
• Quality gates
• Automation
• Reliability
• Security
• Technical debt control

…then teams won’t either.

Engineering excellence is a top-down expectation.

Let’s Be Honest

We all slipped into operations mode at some point. But staying there is not an option anymore.

If we want better engineering outcomes, happier teams, and predictable delivery, then leaders, including me, including you, must return to being engineering leaders, not spreadsheet managers.

This is the shift we must make. And it starts with us.....

Happy Holidays!!