Functional Manager

In a traditional functional organisation, a functional manager is responsible for everything related to their function: hiring, performance, day-to-day work allocation, technical direction, stakeholder communication, reporting, and a long tail of admin. The role exists because the function is the unit of organisation, so someone has to coordinate it.

In an organisation with cross-functional Stream Teams, day-to-day work no longer belongs to the function. This raises a fair question: what do functional managers actually do?

A 2016 Accenture study, published in Harvard Business Review, surveyed 1,800 managers across 14 countries about where their time actually went. 53% on admin — dependency tracking, resource allocation, approvals, status updates. 30% on firefighting — unblocking teams, chasing escalations, patching coordination failures. That left 10% for strategy and 7% for developing people. The most experienced people in the company are spending the bulk of their week on work that doesn't need their expertise.

ZeroBlockers changes this. The role moves into the Product Team, the admin layer is largely removed, and the focus shifts to the parts of the role that always mattered most: developing people and contributing functional perspective to product strategy.

The matrixed organisation

Many organisations try to keep the traditional functional manager role intact while introducing cross-functional teams. Each person reports to a Stream Team for their day-to-day work and to a functional manager for everything else. This is the matrixed organisation, and it has well-known problems: every individual has two bosses with potentially conflicting priorities, and the functional manager spends most of their time trying to keep up with what their reports are actually working on.

ZeroBlockers takes a different approach by removing the matrix.

What functional managers used to do

Functional manager responsibilities historically fell into four buckets:

Admin tasks: resource allocation, budgeting, meetings and reporting, collating and sharing updates.
Problem solving: fixing issues as they arise on projects.
Strategy: strategic planning, identifying opportunities for improvement, process definition, technical leadership.
People and stakeholders: recruitment, professional development, hiring, stakeholder management, team culture, motivation.

The reason the role existed was that someone had to do all four. In a functional structure they were tightly coupled. The manager defined how the team worked, allocated who did what, fixed what broke, and developed the people doing it.

What changes with Stream Teams

Once Stream Teams own delivery, the four buckets split apart:

Admin tasks largely go away. Resource allocation moves to the Product Team's team funding decisions. Reporting is replaced by transparent Stream Kanban boards and the Weekly Product Review. Most of the calendar that used to fill a functional manager's week disappears.
Day-to-day problem solving moves to the Stream Team itself. Issues are surfaced and resolved by the people doing the work rather than escalated up a functional chain.
Strategy splits in two: the Product Team owns the functional perspective inside product strategy (the functional manager contributes here), and the Enabling Team owns cross-product functional craft strategy (capability standards, good-practice playbooks, communities of practice).
People and stakeholder work stays with the functional manager and grows in importance, because the admin time previously consumed by the other buckets is now available for it.

The new role in the Product Team

A functional manager inside a Product Team (typically a Design Lead, Development Lead, Marketing Lead, or other discipline lead) owns:

People development. Coaching, career planning, performance conversations, and growth for the practitioners in their function on the Stream Teams aligned to this product. With admin gone, this is now the largest part of the role.
Functional perspective on product strategy. Bringing deep functional expertise into the product strategy conversation. The Design Lead represents what is and isn't possible from a design and research perspective; the Development Lead does the same for engineering; the Marketing Lead for positioning and growth.
Hiring for the function within the product. Defining what good looks like for new hires in their discipline, running interviews, calibrating performance.
Liaison with the Enabling Team. The functional manager in the Product Team consumes the capability standards and good-practice playbooks produced by the Enabling Team, applies them to their product context, and feeds back where standards need to evolve.
Setting functional strategy at the product level. What does design excellence mean for this product? Where is engineering capability the bottleneck? These are local strategy questions that don't belong at the Enabling Team but do need a functional owner inside the product.

The new role in the Enabling Team

The cross-team craft side of the old functional manager role lives in the Enabling Team, in the Staff/Principal Functional Expert role. Their focus is craft coaching: defining what good looks like for the function across all products, running communities of practice, identifying capability gaps across teams, and feeding the most senior practitioners with the perspective and tools to coach others on their Stream Teams.

These two halves don't compete. The Product Team functional manager develops the people in their product; the Enabling Team functional expert raises the bar across all products and supplies the standards.

Implications

A few practical consequences worth being aware of:

The role becomes about people, not paperwork. The biggest shift is that admin time disappears. People who got into management because they liked the people side of the job get more of it. People who liked the control side may struggle.
The role becomes more strategic. The functional manager has a real seat at the strategy table because their input shapes what the product can do. This is closer to the original intent of "leading a function" than the matrixed version ever was.
Career paths split cleanly. Practitioners who want to stay technical have a parallel senior-IC path through the Enabling Team's Staff/Principal Functional Expert role. Practitioners who want to lead people have the Product Team functional manager path.
The transition is uncomfortable. Functional managers used to a traditional role often experience the change as loss of control. Honest conversations about what the new role includes (and what the cost of staying in the matrix would be) help more than retitling.

Anti-patterns

Keeping the matrix as a transition arrangement that never ends. Two bosses for every individual is a stable suboptimum. Either commit to the Product Team / Enabling Team split or commit to the functional model.
Treating the Product Team functional manager as an escalation path for delivery issues. When a Stream Team has a delivery problem, escalating it to the functional manager re-creates the matrix. The Stream Team is accountable for delivery; the functional manager owns people development and strategy.
Letting admin creep back in. Because the role used to be 60% admin, the path of least resistance is to refill the calendar with reporting, meetings, and resource-allocation conversations. Resist this. The point of the change is that the time goes to people development.
Empty Enabling Teams. Naming a person a "Staff Functional Expert" without giving them the time, budget, or remit to actually define standards, run communities of practice, and coach senior ICs leaves the role as a job title with no work.