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

This module breaks down the specific tools we used to achieve this:

1. Matrix support — new context without a new structure
2. Integrating analysts into development — from documentation straight to functional solutions
3. The 50:30:20 rule — protecting quality and growth
4. Shift-left QA — quality as a competency, not a phase
5. The "rake" concept — from specialists to T-shaped professionals

‍

Starting point: technology silos

Direct had a classic structure that you'll recognize almost everywhere: technology teams organized by discipline—frontend, backend, analysis, QA, database—each with its own team leader reporting up the company hierarchy. A developer was a "frontend person" or a "backend person," and their world ended at the boundaries of their technology.

This structure is great for depth of specialization. But it has one flaw that deepens as a company grows: no one owns the value delivered to the client. Everyone does their piece and passes it on; the result belongs to no one and everyone at the same time.

‍

Step 1: Matrix support — a new context, not a new structure

We didn't have a mandate to dissolve the technology teams. So we didn't. Instead, we added a second dimension: in addition to their technology, every developer was assigned to a value stream (a business segment).

"You're a frontend dev — and you're also in the Rescue Rangers, taking care of the client." "You're a backend dev — and you're also in the Guardians of the Galaxy, working on claims."

This way, every developer had two people to support them, each with a different role:

• Technology Team Leader, aka the "Axe" — develops them in their technology. A technical mentor.
• Business Segment Tech Lead, aka the "Hammer" (the Product Owner's right hand) — responsible alongside them for the business segment's delivery.

And the developer was "at home" in the value stream: that's where they had their team and events like stand-ups, planning, and retros.

‍

How we solved the classic matrix organization problem

Matrix structures have a notorious catch: developers receive conflicting tasks from two bosses. We avoided this with a simple rule:

Work is driven exclusively by the backlog, which is prioritized by the Product Owner. The Technology Lead only assists with the technical implementation and helps with technical tasks that developers handle in their own time. They never provide competing "what" requirements.

This effectively created "fake managers"—people with influence and responsibility, but without a traditional chain of command. The biggest hidden challenge wasn't the setup, but maintenance: ensuring that the different roles communicated and collaborated on professional development. Finding a platform to bring them together regularly took a long time—and it's something I would address sooner next time.

‍

Step 2: Integrating analysts into development

In the old world, business analysts stood between the business and development: they would grasp the need, design a solution, and provide detailed specifications to the developers. The team received pre-digested requirements—and lost touch with why they were building the thing in the first place.

We dissolved the separate analysis team and replaced it with a Low Code Developmentcompetency. LCD developers integrated directly into the teams, and their work consisted of translating business needs directly into functional solutions — rather than into handover documentation:

• we introduced a BPMN engine, where instead of describing processes in diagrams, we created functional processes that ran directly in production;
• we similarly built tools for pricing.

To achieve this, the entire team had to participate in refinement sessions — there were many, but they were necessary for the team to understand what and why they were doing, define their own stories, and take ownership of the tasks.

Some former analysts transitioned into leadership roles: with their deep knowledge of the business domain, an analyst is perfectly equipped to be the Product Owner's right hand. For them, the transformation wasn't a demotion, but a new role.

‍

‍

Step 3: The 50:30:20 rule — how to protect quality and development

A classic problem: technical debt and refactoring never make it into the product backlog because the pressure for new features is always greater. We therefore came up with the 50:30:20framework:

• 50% of time on new development — backlog items, delivering value;
• 30% on personal, team, and application development — education, conferences, refactoring, technical debt, bugs;
• 20% on preparation — refinements, planning, retrospectives, stand-ups.

Key point: it was neither a whip nor a strict rule. The goal was not to hit the ratio every single sprint, but to track the long-term average. When something was urgent, a developer could easily spend a few sprints at 70–80% on new development — and then it would be balanced out again with the Product Owners.

Step 4: Shift-left QA — quality as a competency, not a phase

Imagine the development cycle as a line from left to right: planning, analysis, coding, testing, deployment. In the classic model, testing happens at the very end, on the far right — and a bug created at the beginning is the most expensive to find and fix. Shift-left means moving testing and quality assurance as far to the left as possible, toward the beginning of the cycle, and doing it continuously. The sooner a bug is found, the cheaper and faster it is to fix — while the change is still small.

In practice, this means that quality must not be the last link in the chain. We therefore made QA a a full-fledged member of the team from the very beginning — ensure that quality know-how resides within the team, rather than with someone manually testing everything at the very end. Quality thus becomes a shared responsibility of the entire team, rather than a separate final phase. Specifically:

• QA was involved in defining user stories — helping to establish what "done and high-quality" actually means before coding even began;
• testing and quality control ran continuously within the team, not just when handing off "finished" code to another department;
• we also utilized the four-eyes principle — developers reviewed each other's code and compared it against the visual specifications.

The result: work went into production virtually error-free, and the number of bugs dropped by half (see the main story).

‍

Step 5: "Rakes" — from specialists to people with a broader reach

For the team to deliver end-to-end, it couldn't be composed solely of pure specialists. We started developing something we called rakes .

You know the T-shaped developer pattern: the vertical line is deep specialization, the horizontal one is a general overview of other areas. We wanted that generalist reach to be more than just superficial — for a person to be proficient in several other competencies at a junior to mid-level. The "T" thus grew more lines extending slightly downward — rakes.

The rule was simple and pragmatic: if a team needed a skill for the long term, they learned it—and if they only needed it for the short term, they borrowed someone who already had it. And the borrowed person’s job was to teachthe team, not to do the work for them and then disappear.

This is why teams grew in 2023—from five members to twelve or thirteen. It wasn't growth for the sake of growth. We needed every team to be able to deliver across multiple applications within their value stream—and teaching such a broad scope to a five-person team would have taken forever. That’s why we built teams to include the competencies they need long-term, and people learned from each other within them. This growth had a clear ceiling: it didn't grow indefinitely, only to the size where the team had everything they needed for their scope in one place. Learning takes time, but it was a conscious investment.

The result in numbers: the share of "T-shaped" professionals grew from ~10% (2023) to ~70% (2025). Details in the Flat Structure, Self-Design Scaling, and Competency Matrix module.

Key takeaways from this module

1. You don't need a reorganization to give people a new context. A matrix dimension over an existing structure is a digestible first step.
2. Resolve the two-boss conflict in advance — with a clear rule on who defines the "what" (backlog/PO) and who defines the "how" (technology lead).
3. An analyst is not a bottleneck; they are a future leader. Merging them into development unlocks their domain knowledge where it is most valuable.
4. You can only protect quality and technical debt by setting aside space for them — but as a long-term average, not as a rigid policy.
5. Breadth needs to be consciously cultivated and rewarded, otherwise you will be left with specialists who are just waiting on each other.

‍