< Blog

Committees vs. Working Groups

Hero image for Committees vs. Working Groups
6 min read

Committees of twenty
Deliberate plenty;
Committees of ten
Act now and then;
But most jobs are done
By committees of one.

What are the differences between a committee and a working group? Working groups relax hierarchy to allow people to solve problems across organizational units, whereas committees both reflect and reinforce those organizational boundaries and hierarchies.

Working groups are typically initiated and staffed by people within the "implementation layer" of an organization. A committee is formed to advise an audience external to the committee itself, typically someone in senior leadership. Whereas the working group is open to those who consider themselves operating in the same space as the working group’s problem area, committees are selected by the person or entity they will be advising, and typically are closed off to everyone else.

The important takeaway here is working groups relax organizational boundaries while committees reinforce them.

Distinguishing Characteristics

CommitteeWorking Group
Closed MembershipOpen to all who want to contribute
Members are appointedMembers volunteer (usually)
Findings and feedback are relayed to the sponsor(s) for decision-makingGroup collaborates, individuals decide and act
Fact findingAction/solution bias
ResponsibleHighly accountable
Deliver a reportDeliver a fix
May be politicalPolitics will stop progress
ExecutivesEngineers
Write meeting minutesWiki and Teams Channel
ChairpersonFacilitator

Effective Working Groups

  1. Have a an exceptionally clear goal. "Restore the payroll system" is clear. "Improve Innovation" is not - and deserves an eyeroll. "Design Excellence" is not - hand that one over to a committee.

    A working group is a defined set of people, usually coming from multiple teams or disciplines, with a clear problem to overcome. First and foremost, working groups are created to solve a specific problem facing an organization. When the group is created, make sure the goal is clear and measurable. Or, put another way - what is the definition of "done" when the working group will disband?

  2. Staffed with people who actually have the power to fix things.

    If code is broken the group needs software engineers, if hardware has failed it needs infrastructure engineers. The working group needs all the skills to diagnose, fix, test and migrate a solution. You know what I mean - people who get stuff done.

  3. Have a facilitator.

    The facilitator runs meetings and keeps the group moving forward. Without a clear facilitator, meetings will become ineffective. A facilitator’s job isn’t to say yes or no; the facilitator isn’t the “decider”. Facilitation is about making sure that progress toward goals is being made.

    Oh, and the facilitator doesn’t have to be a manager; facilitation can be a great leadership opportunity for individual contributors. It gives them an opportunity to flex some organization and communication muscles in a different capacity than they might be used to in their day-to-day work.

    Meeting cadence is ideally "as needed". A working group tackling a critical outage will meet several times a day.

  4. Operate transparently.

    Since the problem you’re solving can span your whole organization, chances are that other people outside of the group will be very invested in the work that the group does. The group has to find ways to broadly share progress, get feedback, and operate transparently. Some methods for creating transparency include:

    • Creating a Teams or Slack channel
    • Sending daily or weekly update emails
    • Creating a wiki for the group to use to document ideas and progress

Working Group

When is a working group not a working group?

  1. When it's just another meeting.

    Some "working groups" are a just a group of people meeting on a specific topic with no real accountability or urgency. Study the cadence, topics, and invite lists of meetings. Too often, meetings are maladapted attempts to solve problems. So, if you want to know what parts of a project or organization are suffering the most, pay attention to what the team is having meetings about, how often meetings are held, and who is being dragged into those meetings.

    In particular, look for meetings with long invite lists. Large meetings are less effective than small meetings, but they do convincingly spread the blame around by giving everyone the impression that all parties were consulted, and all opinions were explored.

    Meetings with a regular cadence and with ever-expanding invite lists are not working groups but do suggest something is wrong in that area of the project.

  2. When it's full of senior executives.

    Sometimes when something bad has occurred (e.g., malware has penetrated your defenses, or a key system is down) senior executives suddenly get very involved. This has the unintended effect of slowing the engineers down who are attempting to resolve the issue.

    Sometimes the organization is in such a state of panic that senior leadership members are micromanaging their teams. Software engineers can’t fix problems if they spend all their time in meetings giving their managers updates about the problems. The boot must be moved off their necks.

    In that situation, I would run two war rooms: one where the engineers were solving problems together (an actual working group) and one where I was babysitting the senior executives (not an actual working group). Voila!

  3. When the desired outcome is not crystal clear.


Image Credit: The House select committee holding a public hearing on January 6th events.

(Photo by Jason Andrew for The New York Times) After spending nearly a year investigating the Jan. 6, 2021 attack on the U.S. Capitol, the House select committee that was tasked with scrutinizing the riot is holding a series of public hearings.

Sharing is Caring

Edit this page