The first article in this series helped us dismantle the various forms of communication, isolate common pitfalls, and set realistic expectations for the team. Now we'll dig a little deeper and explore effective communication techniques to help stakeholders, managers, and the development and design team work together in blissful symbiosis.
Makers vs Managers
First, we need to agree that all of these groups exist in different realms of the project. What I mean by this is that each group is involved to a different degree and thus approaches the project with a unique mindset. One of my favorite articles outlining this concept is Paul Graham's 2009 post entitled "Maker's Schedule, Manager's Schedule."
Paul outlines the pitfalls of interrupting a "maker's" schedule with meetings. Managers run on a different style of schedule where meetings and context switching are a regular part of their workday. Makers, such as developers, need large blocks of uninterrupted focus to solve logic problems or hunt down a bug in the system. Remembering, preparing for, and attending meetings pulls the developer out of their "zone." And, as any developer will tell you, getting into that zone is much more difficult than being pulled out of it. This comic beautifully (and accurately) illustrates what happens when you interrupt a programmer.
Minimize the Meetings
First, I'd like to talk to the meeting schedulers. As we just outlined, meetings, or as most developers refer to them, "productivity crushing time sinks," are budgetary black holes when it comes to development. A one-hour meeting with a developer could cost two or more hours in productivity when you consider scheduling, prep and loss of focus. Lullabot Senior Developer, Juampy, wrote a great article on reforming this process. So when are meetings OK? Before scheduling one, ask yourself these questions:
- Could the information be exchanged via email?
- Could this information be rolled into a different, more encompassing meeting?
- Do we need to create a deliverable item?
- Will all invitees be involved?
I see a meeting being a valuable use of time when multiple people are brainstorming an idea and a deliverable needs to be produced as a result. The keystone of the decision being the interactivity of people. In the scope of a project, a meeting where the majority of invitees are present just to listen is a waste of time. Summarize the information in an email or a document and send it to people to read on their own. If the document is well constructed, follow up meetings and Q&A can be avoided completely and you just saved a boatload of time.
If you have decided that a meeting is necessary, consider who is critical to be involved in the meeting and who could stand to simply receive a summary of the decisions made. Inviting people to a meeting "just in case" is just another time sink. Furthermore, when you involve more people in a conversation, the lines of communication increase factorially, which leads to diluted discussions. Information is more easily processed and decisions made more quickly when there are fewer communication channels.
Keeping the meetings to a minimum removes the focus-busting barriers from your production team's workday, but you still need to be in the loop about the project. I've found that most meetings can be easily replaced with email, progress reports, or other project management tools. The benefit to the developers is that they can incorporate these tasks into their schedules in the most effective manner for them. For many stakeholders, however, meetings are how they stay connected to the project. If the meetings go away, other communication methods may fall in to replace them. That's not a bad thing, as long as expectations for how they should be used are set in advance.
Meeting Alternatives
How you structure these ground rules depends on the size and comfort level of both the development team and the stakeholders. A good project manager will sit in between to ensure the proper channels are used and are not being abused. At Lullabot, we often have the entire development team in the same Slack channel as the clients and set up a distribution mailing list for external stakeholders.
Before we get the project up to cruising altitude, we go over the safety speech with the client on how to use these tools effectively. For example, please don't fire off an email for every idea, bug, or individual task that comes to mind. This also goes for Slack pings. Consolidate your thoughts and send them out in a single request. If you truly want to be ignored and miss your deadline, ping the developer every time you send them an email to make sure they got it. Believe it or not, this has happened. Instead, work with the project manager and follow the communication guidelines outlined in the project charter or kickoff meeting. If all else fails, funnel your requests through the project manager and allow them to parse the necessary actions and assign them to the team. We'll discuss more on handling email effectively in the next article.
As a project manager, your place in the communication landscape could be lounging comfortably at the top of the hill enjoying the view, or you might be down in the weeds playing in the dirt. Teams will play nicely together in some projects and could be completely at odds in another. Your job is to keep the information flowing and the project on track.
Set the Ground Rules Early
When kicking off a project, the project manager should get stakeholders, developers, and designers together to discuss the expected frequency of communication and the proper channels to use for certain communications. For example, do you want your developers emailing the clients directly whenever they have a question? Or is it OK for stakeholders to ping developers on Slack every time they find what they consider to be a bug? Defining these ground rules in the project charter or at least in a formal kickoff meeting ensures that everyone is aware of the expectations and the channels are set to make the project run smoothly. It is very easy for clients to feel ignored or developers to feel overwhelmed if neither knows the right method or frequency to address their concerns.
Keep Your Focus
Check in periodically with both stakeholders and the production team. Ensure the communication channels originally outlined are holding up and important information is not falling through the cracks. Make adjustments if needed, like increasing daily syncs or eliminating useless notifications. It’s easier to begin with fewer items in the communication landscape and add more as needed than it is to try and remove them later, so start lean.
Don't Overcomplicate the System
If you have some excellent communicators on your production team and the client is open to working with them, cautiously step out of the way and let the stakeholders and your team communicate directly. Given this responsibility, you might be surprised at the leaders you have hidden behind the screens. As a project manager, sometimes you can simplify the process by removing yourself!
"Don't add process for the sake of process. The fewer cogs in the machine, the simpler it is to maintain." - Jerad Bitner, Lullabot Technical Project Manager
For more resources about effectively managing an agile system, check out Jerad’s article, "Lessons Learned in Scaling Agile."
Block Your Calendar
Lastly, here's a little trick for the production team I used when I worked in a meeting-heavy office environment. Coworkers had access to each others' calendars and could thus schedule meetings based on the attendees' availability, so I reduced my availability. I put two giant blocks of busy time over Tuesday and Thursday and made those my heads-down days.
Create full day events in your calendar for uninterrupted work time.
This technique funneled most of my meetings into Wednesdays. I saved the smaller tasks that didn't require as much focused brain power to fill in the gaps in between meetings and hunkered down to attack the bigger tasks on those heads-down days. It was a huge productivity boost. Sometimes you need to control the communication flow however you can to get the work done.
We've covered a number of ways that the production team can work effectively with the stakeholders, and also how project managers can help facilitate that. Setting the ground rules early and avoiding unnecessary meetings go a long way to boosting productivity without sacrificing stability. The elephant in the room that we've been tip-toeing around is email. It is by far the most pervasive and invasive form of communication and deserves its own article's worth of attention. Stay tuned for the next installment, where we'll discuss best practices as well as tips and tricks for dealing with a deluge of email.
In the meantime, if you have any suggestions of your own, I'd love to hear about them! How do you handle complex communication systems?