People just starting to appreciate the usefulness of management skills often look for the rulebook—a set of concrete proclamations about when to use which techniques and how to respond to common situations.
There is no such rulebook. One of the things that makes management problems so fascinating—whether you are leading a research team, a project, a laboratory, or a department—is the fact that each problem is unique. There are patterns, though, and I suspect that if we fully understood the system we could articulate some rules. But of course, we do not fully understand the system because it is made up of people, and people provide endless surprises. So we can’t write universal rules of management. But that doesn’t mean that we can’t learn from each others’ experiences. There are some high-level guiding principles that can be elucidated and that seem to hold true over a wide range of specific situations.
One such principle is transparency.
In general, projects work more smoothly when all the participants have access to as much of the relevant information as possible. It can be tempting for a project manager to try to control access to information—either for good reasons (such as attempting to prevent misunderstandings) or bad ones (such as attempting to achieve political gain)—but that is almost uniformly a mistake. Studies have found a correlation between a feeling of empowerment and work performance. It is impossible to be empowered when you do not have all of the available information.
Similarly, it can be tempting for a team leader to attempt to control the flow of information, again for good reasons (protecting team members from worry) or bad (limiting team members’ information about other opportunities). That, too, almost always backfires. Studies show that people perform best when they feel engaged with their workplace, and learning that your manager is withholding information tends to decrease your engagement.
A transparent management style allows people to feel comfortable contributing ideas and improves team morale. It also helps you, as the manager, to delegate more of the organizational work and is an excellent way to help junior team members prepare for future advancement. Watching senior team members make decisions in the open is some of the best training available. That only works if the junior members can see the information that went into the decisions.
If you are sold on the benefits of transparency, you may be wondering how best to achieve them. Here is where things get messy. There are many different ways to be transparent with your team, and which of those will work best depends on the personalities on your team, the culture of the larger organization in which you work, and your own style as a leader, among other things.
Here are some tactics, which can be used together or separately, to pursue an open management style:
- Weekly Status Meetings. This is an “old school” technique, but it still works well, particularly if the team doesn’t keep uniform hours. To be useful in increasing transparency, the meetings must include a portion in which the manager shares new information, and encourages other team members to do the same. A weekly meeting works best if someone makes sure there is an agenda ahead of time, and keeps things on track by steering the conversation and cutting digressions short.
- Daily Standups. These meetings are a staple of the Agile project-management method popular for software projects. Daily meetings can be useful for other types of projects, too, particularly ones in which a team of highly independent people are collaborating to produce something. A daily standup meeting is exactly what it sounds like: a meeting held every day, during which the team stands. The standing is to encourage brevity (the meetings are supposed to last roughly 15 minutes). Each team member states what he or she is working on now, what comes next, and if there are any issues blocking progress. In-depth discussion is deferred until after the meeting, when small groups of people can gather to work through any particular issues requiring further collaboration. It usually takes a few weeks for a team to get used to the daily format. Once the meetings are running smoothly, they require little management. However, they do require the entire team to be available briefly each day, and are easiest to run if everyone is in the same location.
- Kanban Boards. These are visual representations of all the tasks under way on a project. A full discussion of these boards is beyond the scope of this short column, but I have described them in detail elsewhere. They work particularly well for teams that have a repeatable process, although the basic idea of visualizing progress can be adapted to different types of work. Kanban boards can be implemented on a computer or on a physical board. The physical board has the advantage of being unavoidable and providing a natural gathering point for team discussions. An online board provides the advantage of being accessible from remote locations. It is not uncommon for teams who are really committed to this approach to have both kinds, and to assign someone to keep them synchronized.
- Public Dashboard. This is a summary of project information, presented in a location that all team members can access. Public dashboards are usually on a computer system, because they work best if they enable easy “deep dives” into detailed data that supports the summary presented in the dashboard. This approach works well for distributed teams that have a hard time scheduling frequent meetings. It is common both in the open-source software development community and in big companies—although the two groups probably wouldn’t recognize each others’ methods as having much in common. There are systems that automate some of the work of summarizing and organizing information, but a successful public dashboard usually has either someone who maintains it or a team with a strong culture of keeping it up to date.
- Shared Folders, Document Stores, or Wikis. A method for sharing written information is almost a minimum requirement for operating transparently. That can be accomplished with a wiki, a set of shared folders, or a shared document store such as SharePoint or Google Sites. Any of those usually require someone to put in the effort of keeping them organized and up to date, and perhaps explaining their use to newcomers on the project. For small teams whose members know each other well and have a solid collaborative culture, the existence of a shared document repository may be all the formal framework needed to support transparency. However, as the team grows, or if there is a team member with a penchant for hoarding information, other methods are usually required as well.
I’ve seen all of these methods done well, and I’ve seen them done poorly. I personally use a combination of methods with any projects I manage. I start by examining the methods required by the larger organization. For instance, it is common for program managers to request that a dashboard be kept up to date. In that case, I like to see if I can make that dashboard useful for my team, too. I’d rather avoid duplicate reporting if I can.
Then I think about the type of work my team needs to complete. I combine that with consideration of the work habits and personalities of my team members to produce a proposed information-sharing plan. I discuss the plan with my team, and together we settle on our approach to transparency. That plan is understood to be open for changes as the work progresses and our needs change.
As with so many management concerns, you don’t have to have a perfect solution to have a method that will do a lot of good for you, your team, and your projects. Just pick something, give it a try, and adjust as needed.