What four hundred and thirty five tickets actually looks like

In my first year at Ascend I closed four hundred and thirty five Jira tickets across nine phases of work. I am leading with that number because numbers like it get used in ways that obscure the work. I want to write what the year was, behind it.

The number works out to about nine tickets a week. That sounds like a sprint pace. It is not. The integer hides almost everything, because tickets are not units of work. They are units of accounting. One ticket might be a three-line correction to a copy string. Another might be the kind of question that takes a week of staring before you write a line of code. Counting them tells you almost nothing about either one.

What the year felt like, week to week, was a steady flow of well-framed problems. The reason I could close that volume was not speed. It was that the work had been clarified before it reached me. The product team had removed ambiguity, the design had been thought through, the dependencies had been mapped, the integrations had been considered. By the time a ticket landed in my queue, the engineering question was a real engineering question. Not “what should we build” but “here is what we should build, here is why, here is the surrounding context, here is what would break if we got it wrong.”

That kind of preparation is not free. It costs a different kind of work, performed by a different person, in advance. But it is the thing that makes apparent velocity possible. I did not ship four hundred and thirty five tickets because I was fast. I shipped them because the company had built an environment where the question I was answering was always the right one.

The pieces of the year I think about most are not the numbers. They are the patterns I noticed about how the work held together, and the patterns I noticed about myself under sustained pace.

The work that does not show up as tickets is often the most important. Observability you set up in week three saves you forty hours in month seven. The hours of code review you give to a teammate compound into days they save later. Documentation written on a quiet Friday is what makes onboarding the next engineer take days instead of weeks. None of these become tickets, but they are what makes the ticket count possible.

The discipline is not in the sprints. The discipline is in the quiet weeks. Anyone can ship hard for a week. The harder thing is to ship steadily across fifty weeks without breaking the systems or yourself. The pace that produces four hundred and thirty five tickets in a year is not a fast pace. It is a sustainable pace, held without flinching. That is closer to running a kitchen than to running a marathon. There is no finish line. You set up the line, you keep the line moving, you fix what breaks, you do not let the line slow.

You will get something wrong. The discipline you have to keep is the discipline to not pretend you didn’t. Some of those four hundred and thirty five tickets were follow-up work on tickets I had closed earlier. I shipped a thing, the thing had a flaw, I went back, I fixed it. The ticket count reflects that loop. I am not embarrassed by the loop. The loop is the work. The engineers I trust least are the ones who never appear to revisit anything they shipped.

What I would say I learned this year, if asked to give it as one sentence, is that velocity is downstream of clarity. The output number is interesting but it is a lagging indicator. The leading indicator is whether the team upstream of the engineer has done the work to remove ambiguity, and whether the engineer downstream of the product team has done the work to sustain consistency. If both are true, the tickets close themselves at a steady pace. If either is missing, the count drops, and no amount of effort closes the gap.

I am writing this with three weeks left in my second year at Ascend. The ticket count is already higher than the same point last year. The work is harder. The system is better. The discipline is the same.