From 3 teams to 1: why I consolidated the platform team at Tranzact

When I took over the platform team at Tranzact Peru, it was split into three: backend, frontend, and support. Made sense on paper — each with its own specialty — but in practice it created something I didn’t expect: too many cross-team meetings.

The problem wasn’t the people, it was the structure

Any feature touching more than one layer (most of them) needed three teams in sync. Each with its own standup, its own backlog, its own notion of priority. Coordination itself had become a full-time job — mine and each team lead’s.

graph TD
  subgraph Before["Before: 3 separate teams"]
    BE[Backend]
    FE[Frontend]
    SP[Support]
    BE -.cross-team meetings.-> FE
    FE -.cross-team meetings.-> SP
    SP -.cross-team meetings.-> BE
  end

The consolidation, in two steps

I didn’t do it all at once — moving everything together would have been as disruptive as the problem I was trying to solve.

1. First, backend with frontend. They were the two teams with the most direct dependencies — most features touched both equally. Merging them cut the most expensive sync first.
2. Then, I added support. Once backend+frontend worked as a single unit, folding in support was simpler — there was already one coordination point, not three.

The result

Today it’s one platform team. Fewer sync meetings, one backlog, one priority. My work shifted from coordinating three teams to leading one — which in practice means more time on architecture and less time resolving calendar friction.

If you’re in a similar spot: the signal isn’t “the team isn’t performing,” it’s “we spend more time coordinating than building.” That’s when it’s worth asking whether the structure is the problem.