Our Dubai Team Shipped 41 Percent More Tickets and Nothing Got Better: the 7 Measurements I Use Instead

A client in Business Bay once showed me a quarterly deck with a 41 percent increase in completed tickets. The team had worked hard for it. Nobody in the business had noticed any difference, the two features the commercial team actually wanted were still not live, and the engineering manager could not explain the gap. The number was real. It was also measuring the wrong thing, and it had taken a quarter of everyone’s attention to produce.

What follows is the method I use instead. It is built around the four delivery metrics popularised by the DORA research programme, with the corrections that matter in this market. It takes about a month to stand up properly and roughly thirty minutes a month to run after that.

Why ticket counts and story points keep failing

Ticket throughput has one structural flaw: the team controls the denominator. Slice work more finely and throughput rises without a single additional line of value reaching a user. This is not cheating, it is a rational response to being measured, and it happens quietly in every team that gets a throughput target.

Story points have the same problem with an extra layer of noise, because the unit is renegotiated every planning session. Comparing velocity across two quarters is comparing two different currencies and reading the exchange rate as growth. Comparing it across two teams is worse still.

The four delivery metrics avoid this because their denominators sit outside the team’s discretion. A deployment either reached production or it did not. A change either took three days to get there or eleven. An incident either happened or it did not. You can still game them, and I will come back to how, but you cannot game them by changing how you write tickets.

Step 1: Agree what the measurement is for, in writing

Before any tooling, write one sentence naming the decision these numbers will inform, and send it to the team. Mine usually reads something like: we will use these four figures to decide whether to invest the next quarter in release automation or in test coverage, and for nothing else.

This sounds like process theatre and it is the highest-leverage ten minutes in the whole exercise. Engineers have seen delivery metrics used in performance reviews before, and if nobody says otherwise they will assume that is what is happening. An assumed performance metric gets managed, which means the numbers degrade before you have collected a single useful one.

Put the negative case in writing too: these figures will not appear in any individual review, and they will not be compared between teams. Then keep that promise, because you only get to make it once.

Step 2: Take a baseline before you change anything

Pull eight weeks of history out of the tooling you already have. Version control gives you commit timestamps and pull request merge times. Your CI or deployment tool gives you production release times. Your incident channel or ticketing system gives you failures and recoveries. None of this requires a new platform, and the exercise usually takes a competent engineer two days.

The reason to do it first is simple: without a baseline, every future improvement is an assertion. I have sat in reviews where a team claimed lead time had halved and nobody in the room could say what it had been. The claim was probably true. It was also unusable.

If you are measuring a newly hired or newly outsourced team, start the baseline on the day they receive production access, not the day they start. Including the ramp period produces a flattering first quarter and an unfair comparison for every quarter after it.

Step 3: Instrument the four metrics from data you already hold

Resist buying a platform in month one. Every one of the four can be derived from records you already produce:

• Deployment frequency. Count successful production pipeline runs per week. If deployments happen partly by hand, count them by hand for eight weeks and fix the automation later. A manual count is better than no number.
• Lead time for changes. Measure from the first commit on a branch to the moment that commit is live. Do not measure from pull request open, which hides the two days the work sat on a laptop.
• Change failure rate. The share of production deployments that required a rollback, a hotfix within twenty four hours, or that triggered an incident. Agree the definition once and write it down, because this is the one people redefine quietly.
• Recovery time. Incident open to incident resolved. If you have no incident process, this metric is telling you something before you have measured anything.

Export to a spreadsheet weekly. A spreadsheet with correct definitions beats a dashboard with wrong ones, and you will change your definitions at least twice in the first month.

Step 4: Correct for the Dubai working calendar

This is the step that is missing from almost every generic guide, and it is where UAE teams get misleading numbers.

The working-week mismatch. The UAE federal week runs Monday to Friday with a half day on Friday, while some teams and counterparties across the region still work Sunday to Thursday. If your team depends on a partner on the other pattern, elapsed-hours lead time will look poor for reasons that have nothing to do with engineering. Measure lead time in working hours against your own calendar and record the dependency separately.

Ramadan. Shortened working hours compress delivery for roughly a month each year. A team that does not annotate it will read a seasonal effect as a regression, and somebody will propose a fix for a problem that resolves itself.

The freeze. Most UAE teams stop deploying around National Day and the Eid holidays. Changes queue up and then ship together, which inflates deployment frequency for one week and lead time for the three before it. Mark the freezes on the chart. Whoever reads it next quarter will not remember them.

Step 5: Report the distribution, never the average

Mean lead time is the single most misleading number in engineering reporting. One change that sat in review for six weeks drags the mean up and makes a healthy team look broken. Worse, the fix for a bad mean is to find and rush the outlier, which is almost never where the value is.

Report two figures instead: the median, which tells you what a normal change experiences, and the slowest decile, which tells you what your worst changes experience. The gap between them is the interesting number. A team with a median of two days and a slowest decile of four days has a steady system. A team with a median of two days and a slowest decile of twenty six days has an approval problem, a dependency problem, or a type of work that nobody owns.

In my experience the slowest decile is where the organisational issue always hides, and it is the figure most dashboards do not show by default.

Step 6: Attach every number to one owned constraint

A metric without an owner is a conversation. Pair each of the four with the specific bottleneck it is expected to expose and the person accountable for that bottleneck.

If a number moves the wrong way and no named person is expected to act, remove the number. You are collecting it to feel informed, which is an expensive habit.

Step 7: Review monthly, and delete anything nobody acted on

Thirty minutes a month. Three questions: what moved, what did we do about it last month, and what will we do about it this month. Write the answers in the same document every time, so that in six months you have a record of which measurements changed a decision.

Then apply the deletion rule. Any metric that has not changed a decision in two consecutive cycles gets retired. Teams accumulate dashboards the way codebases accumulate feature flags, and the cost is not the storage, it is that twelve numbers in a review means nobody looks hard at any of them.

The three ways these numbers start lying

Someone attaches them to a person. This is the fast failure. Lead time becomes a target, so pull requests get split into pieces that each pass quickly while the feature takes longer overall. Change failure rate becomes a target, so incidents stop being logged as incidents. You end up with a better dashboard and a worse engineering organisation, and you cannot undo it by announcing that you were only looking.

The definition drifts. Six months in, somebody decides a hotfix is not really a deployment, or that a rollback during business hours does not count. Each change is defensible and the series becomes meaningless. Keep the definitions in one document with a change log, and treat a definition change as a break in the series rather than a continuation of it.

The sample is too small. A team of four shipping twice a week produces eight data points a month. One bad week moves everything. Report rolling eight-week figures, state the sample size next to the number, and do not draw a trend line through four points no matter how much the slide wants one.

What this method will not tell you

It will not tell you whether the team is building the right thing. All four metrics measure the speed and reliability of delivery, and a team can be excellent at all four while shipping features nobody uses. Pair them with one outcome measure from the business side, even a crude one, or you will optimise a pipeline that delivers the wrong cargo efficiently.

It will also not tell you whether an individual is performing. For that, use the signals managers can actually defend: the quality of the code review a person gives others, the clarity of their written proposals, whether their estimates hold, and structured peer input. Keep that conversation in a different document from this one.

If you are standing up or restructuring a team and want the surrounding mechanics, our guides on auditing technical debt before you hire, building an on-call escalation matrix and hiring a solutions architect in Dubai cover the three areas these metrics most often point at. For stack-level hiring, see product development services in the UAE.

Frequently asked questions

What are the four DORA metrics and can a small Dubai team use them?

The four are deployment frequency, lead time for changes, change failure rate and the time it takes to recover from a failed deployment. They describe the delivery system rather than the people inside it, which is exactly why they work for small teams. A team of five can collect all four from data it already produces: deployment frequency from pipeline runs, lead time from the gap between first commit and production release, change failure rate from the share of deployments that trigger a rollback, hotfix or incident, and recovery time from incident open and close timestamps. The caveat for small teams is volume. With fewer than roughly twenty deployments in a measurement window, a single bad week moves every number, so report a rolling eight-week figure rather than a weekly one and resist drawing a trend line through four points.

Should I use DORA metrics to evaluate individual developers in Dubai?

No. All four metrics describe a system, and the moment they are attached to a person they stop measuring anything useful. The mechanism is predictable: lead time becomes a target, so pull requests get split into smaller pieces that each pass quickly while the feature takes longer overall, and change failure rate becomes a target, so incidents stop being logged as incidents. You will have a better dashboard and a worse engineering organisation. If you need an individual performance signal, use the things managers have always used and can defend: the quality of code review a person gives others, the clarity of their written proposals, whether their estimates hold up, and what colleagues say in a structured peer process. Keep those in a separate conversation from the delivery metrics, ideally in a separate document.

How does the Dubai working week affect these measurements?

It affects them more than most teams expect, in three places. First, calendar effects: parts of the region still run a Sunday to Thursday week while the UAE federal week is Monday to Friday with a Friday half day, so any metric measured in calendar hours will look worse for a team whose dependencies sit in a different pattern. Measure lead time in working hours against your own calendar, not in elapsed hours. Second, Ramadan: shortened working hours compress delivery for roughly a month every year, and a team that does not flag it will read a seasonal effect as a regression. Third, the freeze: most UAE teams stop deploying around National Day and the Eid holidays, which creates a queue of changes that all ship at once afterwards, inflating deployment frequency for one week and lead time for the three before it. Annotate your charts with the freezes or they will mislead whoever reads them next quarter.

How long before DORA metrics tell me anything useful about a new Dubai team?

Plan for one quarter before the numbers support a decision, and expect the first six weeks to be about fixing the measurement rather than the team. In practice the sequence is: two weeks to pull a historical baseline from existing tooling, two to four weeks discovering that deployments were being recorded inconsistently or that hotfixes bypassed the pipeline entirely, and then a clean eight-week window that is genuinely comparable. If you are measuring a newly hired or newly outsourced team, start the baseline on the day they get production access rather than the day they start, otherwise the ramp period contaminates the figure you will be compared against for the rest of the engagement. The one number that is useful early is change failure rate, because it tends to surface a broken release process within the first dozen deployments.

Bryan

Delivery & Offshore Teams Expert at HireDeveloper.ae. Works with UAE employers on delivery setup, distributed team structure and the measurement problems that surface when an engineering team grows past its first process.