Committees vs. Working Groups
Committees of twenty
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 (sometimes called task forces) relax hierarchy to allow people to solve problems across organizational units, whereas committees both reflect and reinforce organizational boundaries and hierarchies.
Working groups are typically initiated and staffed by people within the "implementation layer" of an organization. The goal of the working group is to solve an acute problem or tackle an opportunity.
A committee is formed to advise an audience external to the committee itself, typically someone in senior leadership. Whereas a working group is typically 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 are typically closed off to everyone else.
The important takeaway here is working groups relax organizational boundaries while committees reinforce them.
|Closed Membership||Open to all who want to contribute|
|Members are appointed||Members volunteer (usually)|
|Findings and feedback are relayed to the sponsor(s) for decision-making||Group collaborates, individuals decide and act|
|Fact finding||Action/solution bias|
|Responsible for facts||Accountable for results|
|Deliver a report||Deliver a fix|
|May be political||Politics will halt progress|
|Meeting minutes||Wiki and Teams Channel|
|Enduring||Until goal achieved|
Effective Working Groups
Have a a crystal 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, or take advantage of a specific opportunity. When the group is created, make sure the outcome is clear and measurable. Or, put another way - what is the definition of "done" when the working group will disband?
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 can get stuff done.
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 collabrate is happening and progress 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". For example, a working group tackling a critical outage will meet several times a day.
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
When is a working group not a working group?
When the desired outcome is not crystal clear - i.e. 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. 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.
Meetings with a regular cadence and with ever-expanding invite lists may or may not be working groups, but do suggest something is wrong in that area and a true working group may be needed.
In particular, look for meetings with long invite lists and no real defined target outcome. 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.
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, run two war rooms: one where the engineers are solving problems together (an actual working group) and one where the senior executives (not an actual working group) are receiving updates and studying dashboards. Voila!
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.