Why the org structure of an AI company breaks during growth
While there are five to eight people on the team, the org structure of an AI company exists only in words: the founder makes decisions, tasks are distributed among acquaintances, and this scheme provides maximum speed.
The breakdown begins later — when a second product line, a separate data loop, and the first clients with quality requirements appear.
The first thing to break is the separation of areas of responsibility. Data preparation, model training, quality assessment, and deployment are four different competencies, but the boundaries between them are not drawn.
The question "who is responsible for a drop in model quality in the product" has no addressee — degradation is noticed by the client, not the team.
The second bottleneck is approvals. Access to data, priority changes, release to product, hiring: everything converges on one person. The decision queue grows to several days; engineers either idle or bypass the process and negotiate directly, losing the big picture.
Then comes manager overload. He is simultaneously lead engineer, product owner, and hiring owner: context switches every hour, strategic tasks are displaced by urgent ones, and decision quality drops where the cost of error is highest.
Finally, conflict of priorities. The research team and the implementation team share the same resources — access to labeling, compute capacity, and the time of strong engineers. Without a formal arbiter, the one who is louder wins the dispute.
We break down how this is resolved: which roles to introduce at each stage of growth, where the boundary of responsibility lies, and how escalation is structured without bringing everything back to the founder.
What changes after restructuring the management model
The first thing that becomes noticeable is the decision approval time. While a question goes through several levels, it lives in email and waits for someone else's calendar window.
After restructuring, each class of decisions has one owner and pre-defined boundaries of authority, so a typical decision is closed not in days but in hours.
The second measurable effect is the share of decisions at the team level. When responsibility boundaries are described, seven out of ten questions do not leave the team: they do not need to be approved with anyone; it is enough to record them in the decision log. Only those that change the product architecture or obligations to the customer go up.
From this grows product release speed: the release cycle is reduced from quarters to weeks with the same volume of checks. The longest part of the work — waiting for approvals — ceases to be a bottleneck, and the team spends time on the product, not on correspondence.
A separate metric is repeat escalations, that is, the share of tasks that come back up with the same question a second time. It drops almost to zero when escalation has one addressee and a rule by which the decision is made. Previously, the same question was raised in circles because the answer was not recorded anywhere.
And lastly: a whole class of failures goes away — decisions stuck without an owner. Such a decision was simply not made, and this was discovered only at the release stage. Now every step has a name and a deadline, so there are no "hanging" items in the development plan.
Comparison of management models and escalation modes
The choice of management scheme determines not how the hierarchy is drawn on a chart, but where the dispute about priorities goes and who holds the final decision on an incident.
At the start, when there is one product, any of the models works — divergences begin on the second or third direction, when common data, platform, and labeling are needed by several teams at once.
| Scheme | When it fits | Where it starts to slow down |
|---|---|---|
| Functional model | One product, a common data pipeline, teams assembled by competencies: models, data, infrastructure | A second direction appears — tasks queue up between functions, the product waits in others' priorities |
| Product model | Two or three products with different users, decision speed inside the team is needed | Duplication of competencies, divergence of labeling and quality assessment standards between teams |
| Matrix structure | Products are different, but the platform, data, and infrastructure are shared | Dual reporting blurs responsibility, conflict between managers is resolved in correspondence |
| Hybrid management scheme | Product teams plus a shared platform and a standards council | Works only with defined decision owners and escalation timeframes |
Escalation: what we define in the regulation
In any of the schemes, escalation must have a timeout: if the decision owner does not respond within the agreed time, the question automatically rises one level higher, rather than waiting for their return.
Separately, we define who owns data quality, who owns model release, who owns the priority of improvements: without this, the matrix turns into correspondence, and the product model turns into parallel edits to the same pipeline.
The scheme is chosen by the number of products and the volume of shared resources, and transitions between them happen in stages — we move one team, look at decision-making time and the number of open escalations, and only then move the rest. This way, changing the management model does not stop development.
Stages of restructuring management and escalation rules
Restructuring management begins not with a new reporting scheme, but with a picture of who actually makes decisions. We assemble it from interviews with participants and a review of closed tasks and incidents: actual practice matters, not how roles are described in documents. Then the sequence repeats from project to project; only the depth of elaboration changes.
- Role audit. We define decision classes — from data selection to acceptance of the result — and mark the actual owner of each. The output is a list of decisions without an owner and decisions where there are two owners.
- Decision flow diagram. We draw the path of a decision from framing to release: where it stops for approval and how long it waits. Usually 2-3 idle points without a reason are found.
- Responsibility matrix. For each decision class, we define who decides, who is consulted, and who is only informed. One decision class — one decision-maker, otherwise a dispute returns the task to the start.
- Escalation map. We set levels, response times, and the rule: if there is no answer longer than the deadline, the decision automatically rises higher. Tasks stop waiting for weeks.
- Task handover regulation. We define what transfers with a task: context, readiness criteria, owner, escalation points. Handover stops depending on a specific person's memory.
- Test on a live task. We run a real task through the new rules and measure the decision lead time, number of touches, and escalations. We make edits immediately, not after launch.
- Handover. We give the diagrams, matrix, and regulation to the team, appoint the process owner and the point to look at when there are deviations.
After handover, the rules live in documentation and in task reviews, not in the manager's head — therefore the structure does not roll back to the previous one a month later.
Responsibility matrix and escalation regulations
We hand over not a presentation about values, but a working kit that the team lives by without us. Each document closes a specific question: who decides, whom to go to when a decision is stuck. We test on live disputed situations and edit the wording until they become unambiguous.
- Responsibility matrix — for each process, from task framing for a model to bringing the result into the product, it shows: who executes, who approves, who is responsible for the outcome, and who is kept informed. Filled in by actual roles, not by positions from the staffing table.
- Role description — area of responsibility, boundaries of authority, what the role takes as input and what it passes on, and by which metrics its work is evaluated. A separate block — what the role does not do, so that dual reporting does not arise.
- Escalation regulation — levels of appeal, response time at each, what counts as a reason to raise the question higher, and whom to go to if the decision owner is unavailable.
- Decision-making scheme — a tree from the type of question (model quality, product change, infrastructure, priorities) to the level where the decision is closed, plus the condition under which it returns for review.
- Transition plan — by stages: who duplicates the role during the transition period, at what point duplication is removed, and where control points are.
- Templates and review rule — a decision card, an incident review protocol, and triggers by which the structure is reviewed: growth in requests above the level, approval delays, the emergence of a new direction.
Case: restructuring management in a product team
Before: decision queue on one person
A product team of 40 people, three directions — models, data, analytics. Roles formally existed, but decisions converged on the manager: priorities, releases, access, hiring.
In Jira, an average of 26 tasks per week were hanging with the label "owner decision needed"; average approval time was 9 days. Almost every third question returned for a second round: the area of responsibility was not fixed.
Role duplication made the picture worse — two pairs of "model owners", an analyst and a data engineer shared one report. People did not understand whom to listen to, and team turnover reached 28% per year: strong engineers who were tired of waiting left.
After: three escalation levels
We separated three levels of decisions: technical — with the direction owner, product — with the product owner, cross-team — with the architecture council once a week. Only what changes team composition or budget was escalated to the manager.
Role overlaps were removed: each area was assigned to one person, a disputed one — to an owner with veto power. The escalation regulation fit on one page.
The queue on the manager went from 26 to 6 tasks per week, approval time — from 9 days to 2. There were no duplicate roles left, team turnover fell from 28% to 11% over the year, and the share of questions that returned for a second round — from 30% to 7%.
What to do if the org structure already exists, but escalation is stalling?
If escalation is stalling, the formal scheme almost always describes not what happens in work. Disputed decisions on model, data, and priorities converge on one person, and the approval queue grows regardless of the number of levels on the chart.
The first step is to capture the actual decision map: who decides, who can stop, whom people go to when the formal owner is silent.
Next, shadow roles are almost always found. A person without authority actually decides the fate of a release because he is the only one who understands the model or owns access to data.
Until these roles are explicitly named, any reshuffle bypasses them, and in a month the queue returns to its previous place. The overloaded manager here is not the cause but an indicator: he holds the decision because the junction between areas has not been given to anyone.
Rebuilding without stopping work follows one rule: first decision routes are fixed, then the reporting scheme changes. For each class of decisions, an owner is appointed, a "decide myself" criterion and an escalation point with an explicit deadline.
Until the new route is tested on real tasks, the old one continues to operate — in parallel, with a switchover date.
The transition period is the riskiest part. Two roles may temporarily coexist in one person, but each has its own set of authorities and completion indicator: the share of questions going upward falls, typical decisions are closed at the owner's level.
When the indicator holds for several planning cycles, the scheme can be considered working, not drawn.
Frequently asked questions about roles, escalation, and overload
The transition to a new org structure breaks not on the chart but on people: managers' areas of responsibility change, teams get a second escalation channel. Below are the doubts most often voiced before the start, and how we address them in practice.
Teams resist the new structure — what to do?
Resistance does not come from the role itself, but from ambiguity: who makes the decision and where to escalate. We start with a decision matrix — for each class of tasks, we define the owner and those informed.
When the boundaries become explicit, the conversation shifts from "why this" to setting up the transition period.
How to avoid duplication of functions?
Duplication appears where a role is described through activity rather than through result. We separate functions by artifacts: each has its own output and its own readiness criterion. If two units claim one task, the process owner resolves the dispute, not escalation upward. We review the role map once a quarter.
Can the structure be implemented gradually?
First we assess management maturity: whether there are process owners, whether the escalation regulation works, whether metrics are collected from actuals rather than reports.
Then we take one unit, transfer it entirely, stabilize it for several weeks — and only then replicate to the rest. This way design errors remain in one loop and do not spread across the whole company.
Let's discuss the task and come back with an assessment and plan
To come back with a plan rather than generalities, we need a short snapshot of your situation: how many people are in the team, how roles are currently distributed — from research and data preparation to deployment and support, where decisions get stuck and at what level a task most often stops.
It is enough to describe the current scheme and the main problem: parallel mandates, absence of an owner for the result, escalation "through acquaintances", or a queue of approvals before every launch.
In response, you receive the scope of work, the order of stages, and the expected effect on timelines and decision quality — without abstract promises.
- role map and areas of responsibility: who makes decisions, who executes, where mandates overlap;
- transition plan: sequence of stages from fixing responsibility to working escalation;
- scope of work for each stage with a division of what we do and what remains on your side;
- escalation regulation: levels, response times, and thresholds at which a question is raised higher;
- role requirements: which competencies we cover by redistributing people, which by hiring;
- validation criteria: decision-making time, share of questions closed at the first level, time to put a decision into work.
Describe the task in two or three paragraphs — we will come back with an assessment, order of stages, and a transition plan that can be launched without stopping current projects.
