Are we throwing managing out with the managers?

· business-agility, meetup, management

Mel Kendell presenting at the Melbourne Business Agility Meetup — slide “Managing is bad – or is it?”

The meetup’s answer was: no, we should not throw out managing just because we are rethinking managers.

The strongest distinction from the session was:

Managers are roles. Managing is work. You can remove or flatten manager roles, but the work of managing still has to happen somewhere.

Mel’s argument was that a lot of current discourse treats “management” as bad and “leadership” as good. That collapses several different things together: micromanagement, supervision, resource management, decision-making, prioritisation, coordination, and leadership. The result is that organisations remove managers, but often fail to replace the management function.

Main thesis

The session challenged the idea that getting rid of managers automatically creates empowered teams.

Mel Kendell argued that teams still need:

Without that, “managerless” can become either chaos, hidden overload, or management work dumped onto people who already have full-time delivery roles.

The three “modes” discussed

Mel separated three modes that are often blurred together.

1. Supervision

Supervision is about ensuring work is done correctly and safely. It is not inherently bad. It becomes bad when it turns into power-over micromanagement.

Examples included apprentices, regulated environments, quality, learning, and safety. The point was that supervision is sometimes necessary, even in otherwise mature or self-managing environments.

2. Management

Management was framed as managing the work and the system, not “managing people.”

Good management means ensuring people have what they need to do the work, that work is flowing through the system, and that people are not being drowned by unclear requests, excessive demand, or impossible expectations.

A useful phrase from the talk was the idea that management protects people through the system of work, rather than relying on individuals to heroically protect themselves.

3. Leadership

Leadership was treated as valuable, but not sufficient. Vision, mission, purpose, customer focus, and meaning matter, but they do not compensate for poor management.

The memorable critique was essentially:

“I believe in the cause, but it’s killing me” is not sustainable.

Mel was especially critical of “faux leadership”: aspirational values and purpose language without doing the hard work of aligning systems, priorities, and actual behaviour.

The key discussion theme: removing managers does not remove management

“Provocations” slide: who manages without managers, protecting teams from overload, and internal vs external work management

The Q&A spent time on why organisations remove managers. The discussion suggested that many restructures are financially motivated: flatten layers, reduce headcount, and assume management work will somehow be absorbed by teams.

That is the risk.

Participants noted that when manager roles disappear, the remaining management work often falls to people who may not have the time, skill, interest, authority, or reward structure to do it well.

There was also discussion of self-managing teams and holacracy-style approaches. The emerging view was not “self-management is impossible,” but rather:

Self-management requires more deliberate systems, not fewer.

If a person is removed, the function still needs to be designed into the operating system.

The practical proposal: a better work-management system

The second half of the meetup moved into a practical example system the Mel uses, based on Kanban but not the usual simplistic “To Do / Doing / Done” board.

The critique of many Kanban boards was that they merely show progression. They do not necessarily provoke the right conversations, manage capacity, protect focus, or expose blocked work.

The proposed board had these important columns:

New

Mel Kendell on the “New” column — validating incoming requests before they enter the backlog

Incoming requests land here first. The purpose is validation.

The key question is not just:

Can we do this?

but:

Should we do this?

Requests need to be clear, outcome-based, and tied to value, strategy, roadmap, scope, or some other governing frame. If the request is unclear or low-value, it should not quietly pollute the backlog.

To Do

This is a curated backlog, but Mel avoids the word “backlog” because of the baggage: many backlogs become uncontrolled dumping grounds.

The point of the To Do column is to maintain a tight, knowable list of real candidates for work. It needs regular, ruthless culling.

Do Next

This is the near-term priority queue, with a WIP limit.

This column forces business prioritisation. If someone wants their work moved in, they need to negotiate with the other stakeholders whose work is already there.

That moves the prioritisation conflict away from the delivery team and back to the people who should be making business trade-offs.

Doing

This is the protected work-in-progress column, also with a WIP limit.

Once something is in Doing, it should not be interrupted except for genuinely extreme cases. The benefit is reduced cognitive load: the person or team only has to look at what they are doing now and what is next.

Done

Done is not just completion. It is the value showcase.

Mel emphasised that if work items are expressed as outcomes, the Done column becomes evidence of value delivered. That matters for stakeholder confidence and future funding.

Not Done

This was one of the more interesting parts of the session.

The Not Done column is not just a bin. It is a source of intelligence.

It helps reduce noise while capturing useful data about:

The discussion highlighted that many backlogs are full of “not done” items that have never been explicitly acknowledged as such. That destroys signal-to-noise ratio.

Waiting

The Waiting column was described as possibly the most powerful column.

Waiting is for work that was already in Doing but has become blocked. Once work enters Waiting, the clock starts. The point is to make blockers visible, assign accountability, and stop pretending everything is green.

Examples included missing system access, business stakeholders not clarifying requirements, and code reviews getting stuck because review work is not rewarded.

This column exposes the real cost of delay and prevents teams from being blamed for blockers outside their control.

Strongest insight

The strongest insight was that management is not primarily a person; it is a set of functions that must be designed into the work system.

A bad version of “removing managers” says:

We removed the manager, therefore the team is empowered.

A better version asks:

What management work still needs to happen, where will it happen, who has the authority to do it, and what system makes it visible?

Thanks

← All articles