How to Build Engineering Teams That Think in Systems, Not Tickets

                    _Commits by John_

The Performance Conversation That Changed the Room

During a performance review, an engineering manager highlighted that an engineer had spent several late nights debugging production issues and pushing features. It was presented as proof of performance beyond expectation.
The room expected agreement.
Instead, I said something that made it uncomfortable.

Spending more time is not the same as performing better. Effort alone is not performance. Outcome is.

Yes, features were shipped quickly. But months later, we were still fixing subtle bugs tied to that release. Every small enhancement required touching core architectural decisions. During the product review, assumptions were not questioned. The design was implemented verbatim.
The engineer looked busy. The system was fragile.

In the same period, another engineer worked normal hours. No heroics. No drama. Since his release, there have been no production incidents in that module. He questioned the PRD. He challenged design decisions. He wanted to understand how the feature affected customers. As we scaled, extending his work became easier, not harder.
He was rated beyond expectations.
That contrast exposed something deeper — a flaw not in the engineers, but in what we had trained ourselves to value.

• • •

We Reward What Is Visible, Not What Is Valuable
Most engineering performance systems are biased toward visible work.
Hours spent. Story points completed. Tickets closed. Production calls attended.
These are observable. They are measurable. They make managers feel progress is happening.
But systems thinking is often invisible.
Clean architecture is invisible. Prevented incidents are invisible. Reduced complexity is invisible. A system that rarely breaks does not receive applause.
Over time, engineers optimise for busyness instead of durability.
When that happens, ticket completion becomes the goal instead of system integrity.
And nowhere is this more apparent than in how we treat incidents.

• • •

Prevention Should Matter More Than Recovery
Recovery is important. Incident response discipline matters. Mean time to recovery matters.
But prevention should carry more weight.
If I were to assign weights, prevention should count for 80 per cent and recovery for 20 per cent. It is cheaper to prevent than to recover.

Reducing incidents from 10 per month to 1 is more valuable than reducing recovery time from 2 hours to 30 minutes.
When teams focus primarily on recovery, they build better firefighters.

When teams focus on prevention, they build better architects.
If you celebrate the firefighter more than the architect, you are building a culture that creates a fire incident all the time.
The root cause of this pattern is almost always the same — teams that have been conditioned to think in tickets.

• • •

Ticket Thinking Creates Avoidable Work
Ticket thinking creates the illusion of velocity while increasing fragility.

Architecture gets reworked after release. Hotfixes stabilise features that should have been designed more carefully. Refactoring becomes necessary because shortcuts were taken to meet sprint targets. Adding new modules becomes increasingly expensive because the foundation is unstable.

Velocity looks impressive in the short term. But complexity compounds quietly.
Every new feature becomes harder to ship safely. Every release carries anxiety. Engineers spend more time fixing than building.
That is not scale. That is activity disguised as progress.
So how do you break the cycle?

• • •

How to Build Teams That Think in Systems

Shifting from ticket thinking to system thinking requires deliberate leadership.

Redefine performance. Stop rewarding just hours spent or story points completed. Start recognising engineers who reduce incident frequency, simplify architecture, and make future changes easier. Promotion should reflect ownership of outcomes, not volume of output.

Change what you measure. Track incident recurrence, change failure rate, and the safety of extending the system. Measure the reduction of avoidable work. If every new feature destabilises the system, velocity is meaningless.

Involve engineers earlier. Engineers should not simply implement requirements. They should challenge assumptions, clarify ambiguities, and consider second-order effects. An engineer who takes a PRD verbatim is implementing tasks. An engineer who questions it owns outcomes.

Reward complexity reduction. Promote engineers who simplify flows, clarify domain boundaries, and reduce cognitive load. Complexity is invisible until it explodes. Recognise those who prevent that explosion.

When you start doing all of this, one question inevitably comes up — especially from engineers who have been grinding hard but not seeing the results they expect.

• • •
Promotion Is About Mastery, Not Busyness

Many engineers ask why they are not being promoted despite long hours and visible effort.
Promotion panels are not looking for busyness. They are looking for depth.

Companies are looking to promote masters.
Mastery in engineering is not about writing more code or responding to more incidents. It is about understanding systems deeply enough to design them so that problems do not repeatedly occur. It is about building foundations that scale and optimising for the long term.
Speed and quality are not enemies; they answer to mastery.

• • •

This is ultimately a leadership problem. If we want to build engineering teams that think in systems, not tickets, we must reshape how we define performance, what we measure, and what we celebrate.

Tickets close.
Systems endure.

And endurance is what separates coding from engineering.

*John Ojetunde leads multiple Engineering Teams at Moniepoint
*