Clearing Software’s Biggest Hurdle: Communication

Picture a house. I bet the one I’m thinking of is pretty different.

Even if we start adding requirements — corner lot, mature landscaping, two-car garage, three bedrooms — there’ll still be a gap between what the two of us visualize. Maybe a kitchen island is in must-have territory for you; maybe I’m really picky about crown molding.

In software, everyone has a different version of the project in their head, flavored by different specializations, experiences, and motivations. Mirroring the idea of location in real estate, the three most important things in application development are communication, communication, and communication. Room by room, we have to share our vision for the finished product. Otherwise, well — were you picturing a log cabin?

Let’s take a look at the stages of project communication, common trouble spots, and some tools to help facilitate it in a team setting.

Communication Before the Project

Proper back-’n’-forth begins before any code is written.

Overcommunication is Better Than None

We’re frequently tapped as the second or third team to tackle an idea. You can probably guess at the most common complaint from earlier tries: Stakeholders never really had a clear picture of the project’s status.

The processes, tools, and recurring chats in this article may sound like a lot — and can be. Messages, comments, questions, and requests stack up in a hurry. But it’s far, far better to see it all (with the ability to mute, of course) than reach for your goals in silence.

Stakeholders Have Responsibilities, Too

You’re busy, and we’ll do everything possible to respect your to-do list. As the project’s domain expert, though, you’ll be relied on as an advisor (at minimum) during the build. Your timely feedback, insights, and input help with technical decisions and the all-encompassing realities of budgets and timelines. Make sure someone can make this effort a priority.

A Clear Set of Expectations

Before strategy, design, and/or development kick off, there are a few level-setting conversations worth having — especially for folks who haven’t experienced an application build yet. This primer on what to expect includes:

• How features are approached, balancing effort and need
• Change management and why just is a problematic word
• Why goals determine priorities
• Processes around review and feedback
• Launch, and what maintenance looks like

Communication During the Project

Now we’re movin’. Here’s what keeps the team properly talkative during an engagement:

Internal Status Meetings

We need to talk amongst ourselves first. The meeting before the meeting, if you will. This weekly gathering helps everyone assemble their thoughts, questions, and make the best use of stakeholders’ time later.

Daily stand-ups are popular with some organizations and processes, but we’ve found them mostly unnecessary — as long as everything else in this Communication During the Project section is going well. Temporary periods of daily meetings are great if a specific bit of uncertainty needs resolution, or if small tasks are the priority (like squashing bugs ahead of launch).

Stakeholder Status Meetings

Some questions, concerns, and uncertainties are quicker to resolve “face-to-face,” even if it’s over video. Enter the weekly status meeting, which clocks in at 15–30 minutes. There are extra bonuses, too: Facetime goes a long way towards humanizing an ongoing relationship, and avoids a game of telephone between different members of the team.

Since everyone starts with a different idea of what should be built in their heads, the best software builds carry a little tension. Space to talk through those differences keeps it healthy.

Incidental Questions and Chats

Naturally, communication can’t be confined to short chats at the beginning of the week. Whether it’s the whole team, folks leaving notes for themselves, or anything in between, there’ll be an ongoing firehose of project messages.

The big decision here will be where conversations outside of the usual cadence live. We’ll cover that by discussing tools and trouble spots later.

Progress Follow-up

Did everything happen the way we said it would? If each week starts off with a check-in and set of goals, a progress report seems like a good way to end it.

An email does the trick here, unless it’s really bad news. Scheduling a recurring Friday meeting is a recipe for resentment.

Permission to Pump the Brakes

Custom software comes with custom problems. As designers and developers clear up uncertainty, they’ll inevitably hit new challenges and concerns. The earlier they’re discovered and discussed, the easier it is for the project to adapt to any needed changes.

Members of the project team should be empowered to “stop the presses” and talk through unearthed issues, well before they fester.

Avoiding Communication Trouble Spots

Now that we have a handle on regular communication, here’s where it struggles.

Email Isn’t a Project Management Tool

Email. It’s ubiquitous, it’s easy, and it’s in writing, but steer clear of using it for project management. Reasons include:

• To bring future team members up to speed, you’ll have to forward or manually summarize a lot of private conversation.
• Information will need to be copied into ticket tracking systems, rather than linked.
• Keeping up with an inbox is already a struggle for many.
• Search can be hit-or-miss in an email client.

We’ll talk about the alternative (message boards) in Tools.

Document One-on-one Chats

There’s something worse than email out there, too: one-on-one conversations. It’s easy for details to slowly fade away over the course of a long project, and no one wants a situation where someone’s word is pitted against another.

All of these chats — especially when they arrive at a decision — should be documented and shared with the team.

Seek Out the Hard Conversations Early

Delaying a hard conversation makes it worse. As we’ve already touched on, it’s easier to recover from bad news the sooner it’s delivered. Budget concerns, timeline woes, and feature issues should all be sought out and discussed.

Asynchronous Availability

Prompt, attentive back-and-forth is key, but a process that needs immediate replies is a red flag. Creativity thrives with focus, so dedicated design and development time has to be balanced against communication. Hours instead of minutes, but not days.

Now, there’s still room for spans of increased availability. Periods like launches, bug fixes, and some strategic work benefit from tight feedback loops — it just shouldn’t be an everyday thing.

Helpful Communication Tools

Communication happening is the most important part in all this. How it happens is next. Tools come in third. Not because they aren’t vital, but because they rely on the first two things to be successful.

Here’s a selection of software we lean on for internal and external messaging.

Shared Documents (Google Docs)

Meetings, phone calls, coin flips — everything related to an application should be noted in a shared place. You’ll thank yourself at least once per project.

Google Docs have been good to us, but we’ve also seen success with services like Dropbox Paper and Notion. Anything that’ll let you organize, collaborate, and easily share a library of decisions and conversations.

Instant Messaging (Slack)

An instant messaging setup like Slack is absolutely vital internally. It replaces meetings, documents one-on-one chats, and sets a level playing field for remote employees, as long as:

• Project conversations take place in an appropriate channel, instead of direct messages — even if they’re just between two people.
• Everyone’s on board with the asynchronous availability thing we covered earlier.
• The team knows when a meeting would really be more appropriate.

Externally, instant messaging is a mixed bag. Immediacy is a vice, and the next two tools have a more “responsible” vibe.

Issue Tracking (GitHub Issues)

What’ll this effort take? Who’s responsible for each task? Some sort of issue tracking is needed to organize requirements and the day-to-day of a build. We like GitHub Issues and its colocation with repositories on GitHub, but standards like Jira and Asana also do the trick.

A word of warning, though: Each has a learning curve, and clients often prefer a project manager to triage questions and concerns.

Message Boards (Basecamp)

Something has to replace email, and we usually turn to Basecamp. Threaded discussions are stored and shared, both for the current team and any future joiners. It’s ideal for things like deliverables, concerns that’d touch several issues, and problems in need of triage.

Plenty of other tools have similar features, but Basecamp’s ease-of-use has been hard to replicate.

Adding Custom Tools

With this many tools in play, what’s one more? The need to automate or scale a process (like our weekly updates) makes that process a good target for a custom application. We put together our own client hub, which pulls progress reports, budgets, and links to all the other stuff mentioned so far.

Nailing Team Communication

We’ve hit on a key lesson: Communication is hard, especially when you don’t communicate.

Building a new application puts the onus on everyone to settle in, share, and set time aside to converse as needed. Tools help projects run smoothly, but they won’t incite discussion on their own. If nothing else, remember the three most important things in software development: communication, communication, and communication.