Much has been said about “Google’s 20% time”. In a nutshell, it was a program that allowed employees to spend 20% of their time on self-directed work projects with the intention of enabling employees to come up with Google’s next innovation.
We adopted a similar approach* in my office over three years ago by incorporating Working Groups of multi-discipinary subject-matter experts into our official governance structure. (*amount of time commited by each person varies.)
Instead of encouraging employees to spend their time tucked away in corners working on projects intended to “reveal” them once they are successful, we took a different approach: through the use of collaboration tools, we seeded ideas and made space for people to work on solving enterprise-wide problems together.
The projects that had the most success were completed by a diverse mix of people. While a vision of what needs to be done can be helpful, it’s not necessary.
A mature leader trusts the process. They believe that any problem can be solved with the the right people, methodology and mindset. They are comfortable with the chaos and unfamiliarity each new problem presents and take a discovery-driven approach to framing the problem and investigating potential solutions. They work without answers when there are none; exploring, observing, reading and asking until they find clarity.
Legitimizing “20% time”
If you are interested in creating self-directed work teams within your organization, start by legitimizing the effort. Good intentions quickly take a back-seat to the work pressures of the day unless management is invested in your success.
Create Terms of Reference for your group explaining the gap you are filling, your mandate, membership critieria and expected results. Create a list of initial projects and members. Get it approved by an existing body within your organization. The higher the level of authority of that body, the wider your scope of influence. Listen to the challenges of that body; align your mandate and outcomes to meeting real challenges.
Becoming an official part of a governance structure is very important as it aligns “20% time” to committees and councils that have resources and decision-making authorities. It ensures there is a group to receive the proposals and outcomes of self-directed work teams.
Depending on your Terms of Reference, they can approve proposals, contribute funds, as well as help identify linkages, related projects and potential partners. At minimum, the governance body provides feedback about how well self-directed work outcomes are aligned to enterprise-wide priorities.
Here are some of the commonalities of the Working Groups we coordinated:
- An employee must have their manager’s approval to be on the Working Group.
- Active members are required to spend a minimum of two days per month on Working Group activities and projects.
- An employee’s manager does not manage this aspect of the employees work. All parties are able to schedule an appropriate workload by agreeing to the division of time that will be spent between the priorities of the work unit, organization and enterprise.
- Projects are planned based on resource availability. How many people X how much time they are each able to commit = duration and scope of the project. This often results in phased projects where the first phase may just be stating the problem and creating a wiki page for people to brainstorm potential solutions.
- The work itself is managed by project leads identified for each discrete work package.
- A community coordinator helps cross-polinate ideas and connect people with the right skills and interest to the right projects.
- Working group members do not represent their organization. They are members because of their skills, experience and expertise (personality plays a role here as well).
- Members who are inactive for a set amount of time (say, 6 months) may be moved from the list of active members to the list of inactive members. This helps community leaders identify available resources who have past experience with the Working Groups.
Based on my experience convening and cultivating multiple working groups within government, I offer the following advice to future community leaders:
Find a co-chair who shares your values. You don’t have to be similar; in fact, it’s better if you are each bringing a unique perspective to the leadership of the community.
Recruit members early in the process so that people feel they are part of the decision making. First step: draft your Terms of Reference together.
DELEGATE!! Don’t try to take on everything yourself (this is where I need to take my own advice).
Enable people to sign-up to projects. Assign leads. State the skills required to work on the project.
“On-board” new members by meeting them face to face. Find out what their motivation is for joining, which will help you match their interests/skills to a project. Assign them to a project that is either starting or underway.
Find ways to meet peoples’ needs depending on their motivation for joining. Some people just want to get awesome work done, some people appreciate recognition or rewards, some people just want to be included. If you know what their motivation is you can make sure that people feel appreciated for their contribution and continue participating.
Match new members with someone more experienced. That person answers questions so newbies can familiarize themselves with the concepts and practices of collaborative working. This is another way to avoid becoming a bottleneck.
Communicate as openly and as much as possible.
Default to open.
Use whatever collaborative tools are available. If you have many options, tools (GCpedia, GitHub, Twitter) choose the one(s) that are available to the widest number of people possible. There may be reasons for staying within boundaries; however, question whether these boundaries are real or perceived. They can also change and expand over time.
Some training is likely required on the tools. At least part of the team’s activity will go into overcoming technical barriers (and probably cultural ones too).
Don’t waste people’s time by having meetings about nothing. Meet as often or as little as is needed to get work done.
Same is true for on-boarding new people: if there is no project that meets their skills and interests, tell them that and tell them that you will be in touch with them when there is an appropriate project.
Create an online space where people can make their ideas for a project discoverable and sign-up to work on other people’s projects. This provides a framework for how many active projects the group can support: only as many as resources available.
Host working sessions (we call these lots of different things – codesprints, work bees) rather than holding meetings to talk about stuff that you’re then going to have to do some other time.
Ask people to take on tasks or projects. You have no idea how much people will do if someone just asks them. Not everyone can observe online activity and just know what needs to be done.
Dont’ be afraid to call people on the phone. Ask them how they are doing. Have office hours specified to help manage your work load while being available to your colleagues who may want to call you.
Most of all : have fun and celebrate success (and failure). Learn. Grow. Cherish.
And not least of all: listen. Listen to feedback, to people’s sticking points, to what’s going on around you.
Draw your own connections and conclusions.