Seven Strategies for Success
1. Use wikis and collaboration tools
E-mail attachments are inefficient and create versioning headaches; internal websites and repositories controlled by one individual or with limited access controls prevent people with key knowledge from sharing it and create information bottlenecks. Something I've successfully done in two different teams at IBM and am starting to do again in my current job, is to introduce and encourage the use of a wiki, a website that is editable by everyone, for everything from collaborating on documents or designs to reviewing documents and creating new starter guides. The impact on a team can be significant, not only does everyone have a single point of reference and a "place to put things", but every team member is empowered to share his insights and correct things himself when he finds mistakes. Wikis such as MediaWiki and MoinMoin can be installed freely and easily. Enterprise wikis such as Confluence can be very powerful for larger organisations. And it's not just wikis, introducing tools for social bookmarking, internal blogging and instant messaging such as Lotus Connections can empower a team by giving them easier access to the people and information they need to do they job. There are many free tools that can allow people to collaborate more effectively, such as EtherPad, a multi-user Notepad replacement, MindMeister, a collaborative mind-mapping tool, or even just making use of Google Docs and Spreadsheets when collaborating on documents. Task tracking tools such as BaseCamp or ActiveCollab are well worth a look as well.
2. Use agile work methods & tools
I also developed a custom agile work-tracking tool for the team which allowed the work to be tracked easily. A system like this can be used by individuals and management to get a view of the work at the level that is most appropriate for them. By mounting a monitor on the wall and holding the daily scrum gathering around the screen it also provides a way to quickly update status and percentage complete on all work items. Making agile development work effectively is a fine balance between tracking work by setting precise and realistic targets and avoiding micro-management or over-documentation of work.
3. Understand your users
A key aspect of the user interviewing process is that it is performed by the very people who will later design the software, instilling in them a huge amount of empathy for their users, and a greater awareness of their goals, motivations and mental models. In the months after the conference I applied these techniques with my team at IBM, and initiated a round of user interviews with more than a dozen customers, gaining some great insights into their use of the product and their needs. We were then able to use the output of these interviews to generate a report and a primary and secondary persona for use in future design discussions. The user persona serves as a tangible reminder of that understanding which is much easier to remember and conjecture about than a dry requirements document and can then be used for scenario-based development (creating stories about the users and how they use your product in order to design product features).
You may not immediately see the link to team productivity, so let me explain. Going through an exercise like this, to improve the team's understanding of the users or stakeholders of the product or service (every project has these!) and their needs, not only avoids wasted efforts and misdirected designs but also gives the team members the feeling that their work matters to someone, that it will make a difference. This is likely to make more enthusiastic and dedicated team members, who will receive a huge motivation boost when they can their work making users happy... I believe everyone wants to do something that matters to somebody.
It was a helpful side effect of this work that I also learned how to effectively interview people about their needs, mental models and priorities - which will doubtless be of use as a team productivity consultant!
4. Favour Face to Face Communication
E-mail has some advantages: It's nice for the writer to be able to express their thoughts clearly and instantly, and it's a good way of sending documents quickly, but that is where the advantages end. E-mails are ripe for misinterpretation, and encourage batting away responsibility, arse-covering via cc, and can easily facilitate positional or adversarial thinking. Worst of all, e-mail can fill up people's days with the illusion of work, answering emails and dealing with them by forwarding or replying, creating yet more work for someone else instead of getting something done.
Face-to-face communication at the other end of the scale, has no such disadvantages, and allows matters to be resolved cooperatively and quickly. It's hard to reject or divert a face-to-face enquiry or comment in the same way you might an e-mail. In environments where face-to-face is not an option (remote working for example), video conferences can provide an excellent alternative and can be done easily and cheaply with basic webcams, microphones and software such as Oovoo. There is often a strange reluctance to use webcams in corporate environments, but the greater effectiveness over a standard telephone conference call is undeniable. Conference calls too, can now be done cheaply with SIP/VOIP clients or other telephony products such as Google Talk or Skype. In my experience, telephone conversations are almost always more effective than written communication. The next best option is instant messaging, much intonation and non-verbal cues are lost, but timing and the ability to quickly clarify means that it can be a lot more effective than an e-mail. This isn't just my opinion, studies have confirmed the productivity drain caused by e-mail.
5. Encourage creative innovation
6. Tweak the environment to encourage "flow"
To make flow more likely, you need to make sure the conditions are right: Goals and expectations should be clear, team members should be suitably skilled. Distractions (such as IM, phonecalls, meetings and admin) should be minimised. The team should be able to work in large blocks of time without having to watch the clock for the next meeting. The team should be able to work without feeling self-conscious, without feeling micro-managed and without too many people getting involved.
The task itself should be rewarding, and should be understood well enough that it is not too difficult, but equally it should not be boring. And perhaps most importantly there must be some mechanism of easily obtained feedback along the way, so that the team can quickly make adjustments without having to wait for approvals or feedback and losing focus.
It will not always be possible to satisfy all these things, but an understanding of these influencing factors in the psychology of work can help a team to be more productive. I've been part of teams in flow, and it's a fantastic win for everyone involved - the job gets done more quickly and everyone involved enjoys the experience.
Another technique or tweak that can be used to optimise a team is to ensure that people are well-matched to the sorts of task they are being asked to perform. How often have you been employed for a role on the strength of your past CV, only to have that past experience completely ignored when it comes to deciding what work to assign to you? It is important for team leaders and managers to take into account individuals' fortés when placing them. One way to do this is to have everyone take a short test and work out their Belbin Team Role such as Plant, Completer-Finisher or Shaper. Considering the person's natural strengths in comparison to possible roles in the team, and matching them carefully so that everyone can harness their strongest abilities in their tasks will doubtless improve team effectiveness.
7. Value the people
The same is true on a local scale, team members will find it much harder to conflict with each other if they understand each other better. At IBM I was part of the steering group of Hursley Technical Community, a cross-department focus group aiming to foster a better community spirit among the technical teams. We supported the growth and creation of "SIGs" (Special Interest Groups) where like-minded people from different teams could share ideas - for example this might be a Testing SIG, Linux SIG, a Web 2.0 SIG. We also ran many events, workshops, "lunch and learns" and other events, and created a framework so that anyone could run a talk for anyone who was interested, on any subject of interest. I observed that people discovered common interests and made connections they would not otherwise have done. This benefitted everyone involved because ideas and approaches from different departments could be shared, and people increased their networks, being able to draw on those new contacts again when they needed help. This is something that works really well in an organisation with departments that are "silo"-like, and do not mix much.
Similarly, this approach can also work very well within a small team. By encouraging people to present something to the team that they are interested in, from their latest digital photography project at home to a new code testing tool they had designed to make their job easier at work, you increase the possibility of new collaborations forming, and most of all you make sure that your team members "get" each other. They may disagree in future, but a background understanding of what makes the other team member tick will make any conflict far less serious. I think this sort of activity, coupled with the creation of things like "for sale" forums or "advice" mailing lists and newsgroups can really stimulate a sense of community in a team. Above all, managers should remember that they have a room full of people, not "resources" , and that by investing in the people and supporting them in their own goals, they will reap the benefits in terms of that employee's productivity. As is often quoted, "A happy employee is a productive employee." The managers I remember most favourably are those who recognised that this is one of the most important factors in managing someone, and I believe they got the most out of me for doing so.
Thank you for taking the time reading my insights and ideas about team productivity. As you can see, many of the past experiences I've had in business and beyond have given me some deep insights into how to make teams more effective. In this post I have tried to cover some of the key areas but have still only scraped the surface of what is possible. I hope you found something useful. Whatever your thoughts, I'd love to hear them - feel free to post a comment! And in the meantime I will continue planning how to convert my insights and skills on team productivity into a marketable service!