An Airtight Team Is Built Beyond Boundaries ── What to Do With the Time AI Frees Up
Hi! I’m Tsuji, a server-side engineer at AnotherBall.
Most days I’m writing backend code, or chasing an infrastructure alert down a rabbit hole and shaving a yak somewhere along the way.
What to Do With the Room AI Frees Up
How is AI working out for you these days?
AnotherBall is no exception — we use AI company-wide, for development and for plenty of things that aren’t development.
How AI Put Our Company Into BAKUSOKU Mode
Once AI is part of how you work, a question shows up that everyone seems to be asking: what should humans be doing? The answers you hear back tend to sound like “contribute to the bottom line” or “create real value.”
For years, engineering teams have measured themselves with Four Keys[1], which came out of Google’s DORA research.
DORA is a research program run by Google Cloud that keeps asking the same question year after year: what does a software team need in order to deliver value quickly and reliably?
Held up against that question, I’m not sure Four Keys still works as a yardstick in the AI era.
DORA has changed the metrics several times since 2023.
- 2023: MTTR was renamed and redefined as
failed deployment recovery time - 2024: a fifth metric,
deployment rework rate, was added, taking the set from four to five. The groupings were reorganized into Throughput and Instability - 2025: the report was renamed, from
Accelerate State of DevOps ReporttoState of AI-assisted Software Development Report - Sources: DORA’s software delivery performance metrics[2] / A history of DORA’s software delivery metrics[3]
You can read that as a shift in emphasis, from how fast you move to how little you break. Which makes it hard to argue that the right thing to do with the freed-up time is pour it straight back into development.
Does Faster Development Mean Faster Value?
Let me answer my own question.
The short version: development getting faster doesn’t make value arrive faster.
Have you read The Goal by Eliyahu M. Goldratt? Great book, and worth asking your company to expense.
The idea at its center is the Theory of Constraints: unless you deal with the constraint in the flow of work, what you do never shows up in the result.
So when development speeds up, or an individual does, and that wasn’t the constraint, the output of the organization stays where it was.
Back to DORA for a moment, because the reports show the same pattern.
- 2024: for every 25% increase in AI adoption, delivery throughput fell 1.5% and delivery stability fell 7.2%
- The same survey found individual-level measures rising across the board: productivity +2.1%, flow +2.6%, and so on
- Individuals got faster. Delivery as a whole did not. That is the same shape as the argument in The Goal
- 2025: the relationship with throughput flipped from negative to positive, while the relationship with instability stayed negative
- Sources: Accelerate State of DevOps Report 2024[4] / State of AI-assisted Software Development 2025[5] / Announcing the 2025 DORA Report[6]
These are correlations drawn from a survey, not causation. The direction still lines up with what the Theory of Constraints predicts: individual speed and delivery speed come apart.
Which is why the Avvy team runs Scrum, uses Linear, and put a custom kanban on top of it so bottlenecks are visible.
Using AI Coding to Detect Team Stagnation: Building a Custom Chrome Extension Kanban
Bottlenecks move around, so pointing at one and calling it permanent doesn’t work. On our team, though, the hard and high-priority work had a habit of piling up on the PdM.
The Weight of the PdM Role
Job titles mean different things at different companies.
On the Avvy team, the PdM holds the company vision, the product’s philosophy, the goals for the quarter, and a pile of other variables in their head at once, then turns abstract strategy into something concrete. It’s a hard job.
If working across levels of abstraction interests you, this book covers it well (in Japanese).
The obvious move is to spend the freed-up time helping out. Given how hard the role is, it isn’t that simple.
Even where help is possible, you don’t want to end up with the PdM, who owns the outcome, losing track of the product and the people.
Crossing Boundaries Without Leaving Your Post
Long before AI showed up, I’d landed on this as the thing that matters on a cross-functional team: keep your responsibility clear, and cross function lines.
Crossing function lines is what people usually mean when they talk about crossing boundaries.[7]
For the reasons above, though, crossing one isn’t easy. So here’s a case where it happened naturally on the Avvy team.
It started when someone who uses our internal admin screen came to me. They’d written up a set of improvements and wanted a second opinion.
Internal tools like an admin screen aren’t so much low priority as never written down at all. Someone has to shape the work into an Epic before it can even be ranked against anything else. Until that person shows up, the work never starts.
The kanban I mentioned earlier surfaces cards that are sitting still. What was never on the board stays invisible.
This had been bothering me for a while, so a PdM and two engineers sat down and went through the list.
Looking at it, the requirements and the design needed a bit more work, but the cost looked low and the value to the people using it looked high. That let me say: we’ll gather the requirements on the engineering side and come back with a proposal for what goes into the sprint.
Structurally, engineers picked up the context, shaped an Epic, handed the conclusion back to the PdM, and then carried it out. It starts with the PdM and returns to the PdM, which is the same shape as a SubAgent in AI terms.
The parts that matter:
- The final call stayed with the PdM
- The PdM knew what the engineers were doing while they did it
- I kept doing my own job
The third one is the one to protect. It’s what respect for the person whose territory you stepped into actually looks like.
I know nothing about American football, but there’s a post I’ve kept coming back to for years.
アメリカンフットボールには「オーバーパシュート」というアンチパターンがあり、これは「自分の役割を逸脱してボールを止めにいくこと」なんですけど、社会人プレーヤーとしてこれをやってしまうのは本当に恥ずかしいことですよ。
— 全年齢リツイート先生 (@otiai10) May 26, 2019
逸脱が、ではなく、「チームメートを信頼していない」ことが、です。
The post is in Japanese, so here’s the gist. American football has an anti-pattern called over-pursuit: leaving the role you were assigned to go stop the ball yourself. What’s embarrassing about doing it as an adult player, the author says, isn’t the deviation itself. It’s that the deviation says you don’t trust your teammates.
When something you could fix is sitting right there in front of you, it’s hard not to reach for it, and reaching for it feels like the right call. That post is what made me see that it isn’t always.
On Beyond Boundaries
I like this phrase, which is AnotherBall’s vision, enough that I once told our CTO @tatsushim we should be using it in more places. The boundaries aren’t only the national kind. They sit between teams and between people too.
This post has been about crossing them, and about what’s on the other side.
It’s never easy. Boundaries vary in height, and some can’t be crossed, some don’t need to be, and some shouldn’t be.
Getting past that difficulty is where the trust, the results, and the sense that the work was worth doing come from.
Stack up enough of those crossings and the gaps in a team start to close. Responsibility is clear, so nobody wonders whose job something is. Functions overlap, so when someone lets go, somebody else can catch it. An airtight team is probably just that state.
Keep your responsibility clear, cross function lines. If that’s the one line you take away from this, I’ll be glad.
We’re Hiring
AnotherBall is full of people who want to build something good and want the team around them to be good too. The door is open, so come talk to us.