The allocation meeting before PI planning went well. The release lead sat down with the three functional managers who own the engineers on the payments release: backend, mobile and QA. Each one signed off on a share of their people. Two backend engineers at full time, one mobile engineer at 60%, a QA analyst at half her week. Scope was sized to that roster, and the team voted four fingers for 18 June.
Four weeks later every name on the roster was still there. The mobile engineer had been asked by her functional manager to cover an app-store compliance fix for another product. The QA analyst’s manager moved her to a regulatory test cycle for two sprints. One of the backend engineers was spending mornings on a platform migration his own manager had prioritised. Nobody on the release had been told in advance. The roadmap still showed 18 June in green.
What a matrix organization is
A matrix organization is a structure in which people report along two lines at once: to a functional manager who owns their discipline (engineering, QA, design) and to a project or product lead who owns the work they are assigned to. The matrix organizational structure exists to share specialists across several initiatives instead of locking each person into one team.
Matrix management comes in degrees. In a weak matrix organization the functional manager holds most of the authority and the project lead coordinates. In a strong matrix organization the project lead holds most of it. A balanced matrix splits it. The type matters here for one practical reason: it decides who can move a person off the release without asking. In the functional manager vs project manager split, that is usually the functional side.
The allocation a team agrees with its functional managers before the vote is expert engineering judgment. The people in the room know which specialists are shared, which managers are under pressure and which percentages are realistic. That knowledge is part of the evidence behind the confidence vote, and nothing in this article replaces it.
The second boss changes capacity after the vote
The allocation is agreed once. After the vote, the other line of the matrix keeps making decisions about the same people:
- Pull-aways for the functional side. An audit, a compliance fix, a production escalation that lands in the discipline’s queue, not the release’s.
- Another project’s crunch. A shared specialist is moved to whichever initiative is loudest that week.
- Split allocations that deliver less than their percentage. Sixty percent on paper becomes forty in practice, because hand-offs between two sets of priorities cost time.
- Swaps. The functional manager replaces one engineer with another who is new to the codebase.
None of these adds an issue to the release. The board looks the same. That is a capacity change, the third of the three things that erode a committed release date. It rarely travels alone: a shared reviewer moved to another project turns the release’s pending reviews into a dependency, and a team short on people is the one that accepts a small extra ask without re-checking the date, which is scope.
The allocation sheet is rarely re-read against the date. When it is, it answers the question it was built for: who is assigned, and at what percentage? It does not answer the one that matters after the vote: what does this pull cost the committed date, in days?
Keep the matrix. Price every move on it.
The answer is not a stronger matrix or a policy that freezes people in place. Functional managers move people for good reasons. The answer is to treat the agreed allocation as an assumption and re-read the date whenever the other line of the matrix changes it.
- At planning, write the committed date and the confidence level the team voted at next to the allocation each functional manager agreed.
- Agree with functional managers that a known pull-away is announced before it starts, with the days it covers.
- Record those days as time off against the person’s account for the release, not as a new percentage on a spreadsheet.
- Read the re-forecast and send the number back to the functional manager who made the call.
- At every sprint boundary, read the gap in days between the committed date and the forecast at the committed confidence.
An illustration, not customer data. A release is committed for 18 June at 85% confidence. At the vote the 85% forecast sits at 15 June: three days of margin. After the vote, the QA analyst’s two-sprint regulatory cycle is recorded as time off on her release days, the mobile engineer’s compliance week is recorded the same way, and the backend engineer’s mornings on the migration are not recorded at all. They show up as slower completed work in the next two sprints. No issues were added. The 85% forecast is now 23 June, five days past the commitment. The 50% forecast is 17 June, so the release reads amber, not yet red.
Now the conversation between the two lines of the matrix has a number on it. Can the compliance fix wait one sprint? Can QA borrow a tester from another squad? Does a Should-have move past the cut-line? Is the date renegotiated while there is still margin to trade? Every option belongs to the people who own it. What changes is that the functional manager and the release lead decide it with the same figure in front of them, the week the person moved.
Where Advanced Release Planning fits
Advanced Release Planning for Jira does not model the matrix. It does not store reporting lines, the matrix type, functional managers or allocation percentages. It reads the inputs a pull-away changes, at the source. Time off is recorded per person, per day, against the Jira accounts assigned to the release’s issues, so a known loan or reassignment lowers capacity only on the days it covers. A move nobody recorded, such as mornings spent on another manager’s priority, registers through delivered throughput as the release’s completed work slows. Both are folded into the Monte Carlo forecast through the Capacity Awareness setting. The committed date is re-forecast and the shift is reported in days against the 50%, 85% and 95% bands. The team sets the assumptions: which throughput window, whose capacity, what is in scope. The app does the arithmetic at Monte Carlo scale and keeps it live. Green at or above P85, amber between P50 and P85, red below P50.
For the allocation decision itself, see why resource allocation is decided once and the reallocations never get priced. For the roster check that comes before it, see resource availability is confirmed at the vote. For exactly what the app reads, see the capacity change tracking reference doc.
Key takeaways
- A matrix organization gives each engineer two lines of authority: a functional manager and a project or product lead.
- The allocation agreed with functional managers before the vote is expert engineering judgment and part of the evidence behind the confidence vote.
- After the vote the functional side moves people for audits, escalations and other projects, usually without adding a single issue to the release.
- Record each known pull-away as time off before it starts, read the gap in days at every sprint boundary, and share the number with the manager who made the call.
FAQ
What is a matrix organization?
A structure where people report to a functional manager for their discipline and to a project or product lead for the work they are assigned to, so specialists can be shared across several initiatives.
What is the difference between a strong and a weak matrix organization?
In a strong matrix the project lead holds most of the authority over people’s time. In a weak matrix the functional manager does, and the project lead mainly coordinates. A balanced matrix splits it.
What is the key problem with a matrix organization for a release?
Two managers can make decisions about the same person’s week. When the functional side moves someone after the vote, the release loses capacity that its committed date was built on, and nobody reads the cost in days unless it is recorded.
Agree the matrix at the vote. Keep the date honest after it. See every pull-away priced against the committed date in Advanced Release Planning, or start a free trial on the Atlassian Marketplace.
Leave a Reply
Your email is safe with us.