This article provides a detailed look at the flat structure of engineering teams during Direct's transformation.

This module breaks down three interconnected topics:

1. Flat structure in practice — what it looked like and what did (and didn't) change
2. Self-design scaling — self-organized scaling for growing teams
3. Competency matrix — how to make horizontal growth measurable

‍

April 2025: from matrix support to a flat structure

When formal roles and hierarchies were abolished in April 2025, I thought it was just a step we were all already living: "front-enders" and "back-enders" had long since become Rescue Rangers, Legends, Guardians, and Migrants. Hardly anyone said "I'm a frontend developer"—they said "I'm a Migrant" or "I'm a Legend." We just had to draft a few guidelines with the People and Culture team and the lawyers to finalize the formal side of things.

New roles

• Developer — a unified role (on the market today, more likely software engineer or product engineer; in my view, the same thing).
• Technology lead — usually former team leaders. They are now responsible for the technology as a whole and act as mentors: not in the sense of "training and babysitting," but ensuring that competencies around a given technology are developed and that the technology backlog is maintained across applications.
• Development lead — the original "doers," the right hands of Product Owners; they are responsible for end-to-end delivery.
• Agile coaches — on the same level; they have finally moved closer to the product teams and the organization.

We started building a team-based organizational design with teal and self-design principles.

How it worked in practice

All 70 people were grouped together in one team directly under the Engineering team. Nothing dramatic changed in the day-to-day operations. Every developer knew which technology lead would help them with their development and which development lead was their partner in their business segment.

An interesting change was in what the leaders "see." Historically, team leaders had people in their structure, so they also saw organizational details (salaries, vacations). Technology leads and "doers" suddenly didn't see this — and they had to get used to it. We were shifting responsibility to the people.

Self-design scaling: how to scale a team that has outgrown itself

As teams grew to 12 or more people, we ran into a classic problem: a large team has poorer coordination and communication. The classic solution is to split it from the top down and assign the work. We took a different path — self-organized, using a self-design pattern:

• The team always worked from a single shared backlog.
• Refinement was done by the entire team — everyone understood the big picture and the direction.
• At planning , the Product Owner would come in, show the priorities — and the team would self-organize into micro-teams (smaller groups) based on the work.
• Sprint work then proceeded in small, efficient micro-teams.

In a nutshell: they refined as a whole team and sprinted as efficient micro-teams.

The key takeaway: no one split the teams or dictated who worked on what. People divided themselves based on the work and their skills, sprint after sprint. It was the exact same capability that proved successful during the crisis in the summer of 2024 — only now it was mastered consciously and repeatedly.

‍

Competency matrix: how to make horizontal growth measurable

To ensure that breadth (the "T-shaped" approach) wasn't just a buzzword, we needed to make it make visible. We created a competency matrix with two axes.

Axis 1: technical skills — in detail

Not just broad categories like "backend / frontend / database / mobile," but specific key competencies for each technology. Here, we discovered something important:

People learn much more actively when they know exactly what they are learning. Few backend developers wanted to learn "frontend" (styles, layouts). But "working with JavaScript logic"? That felt like home. And conversely—those who wanted to move into backend were intimidated by server configuration, but "designing an API" was appealing.

Breaking things down into specific competencies (rather than just technologies) wasn't just administrative work—it was a driver for learning.

Axis 2: seniority in a given skill (levels 1–5)

Each skill had a proficiency level:

• 1 — contributor: I can set up a project and modify basic elements (e.g., in React, changing a variable, checkbox content, or extending a form);
• continuing through junior and senior to architect.

Each level had a description of the required skills. And one extra clever rule: to become a senior in any competency, you had to mentor someone less experienced. This way, we systematically—not voluntarily—built mentor-mentee relationships into the company.

(insert visual: sample competency matrix + graph showing the development of the number of competencies per developer over time)

‍

A big surprise: the ratio of "generalists" jumped to 70%

A number that surprised even me.

What helped: there used to be a hidden barrier— "I'm a frontend developer, I'll get more money once I'm a more senior frontend developer." We started saying clearly: we will increase pay for growing horizontally, too. And it wasn't just a slogan—it had a concrete mechanism. At Direct, pay was evaluated every six months, and during that evaluation, we looked directly at the competency matrix: a person's horizontal growth (new competencies, higher levels) was one of the inputs used to determine whether they were eligible for a raise. No one had to specifically ask for it—growth was visible in the matrix and reflected in the evaluation. To me, a person who masters more competencies is at least as valuable as a narrow specialist. Money wasn't the only motivation, of course, but it's simply the easiest way to visualize that progress.

Caution—the goal It has never been about having only full-stack developers or only generalists, or only specialists. It has always been about a healthy balance. Depth is still necessary; it’s just no longer the only way to be valuable and grow.

‍

Key takeaways from this module

1. A flat structure works when it only formalizes reality — not when it forces it prematurely. Change how you operate first, then change the org chart.
2. You don't have to cut a large team from the top down. The self-design pattern (one backlog, refining the whole, self-organizing during planning) scales without micromanagement.
3. Break down competencies into detail — people are more willing to learn when they see a specific skill, not an abstract "technology."
4. Build mentoring into your definition of seniority. "Senior = mentor" makes developing others a duty, not a volunteer activity.
5. Reward breadth, not just depth — otherwise, people will stay barricaded in their specializations and end up waiting on each other.

‍