Building software with people

Building software is typically a team sport. Delegation of responsibility carries obvious benefits but with every additional body, there’s a tax added to the process. That isn’t to say building in teams is bad; it’s generally the only practical way to do it. But building software this way presents unique challenges that are ignored at your peril. At best, these challenges add subtle friction to the process. At worst, the entire effort becomes a slave to the foibles of the group building the thing.

So what are these challenges I’m speaking of? There are several forces capable of derailing the best laid plans but the #1 culprit in my experience is communication, or lack thereof.

On communication

At first glance this may seem painfully obvious. Everybody knows communication is crucial. But why then are we still bad at it? Because it takes deliberate effort to communicate well.

An example:

• You have a team of 5 people contributing to a new feature: A product manager, a designer, a couple of developers, and a customer support rep.
• Each is an expert in their domain, bringing a different perspective to the process (and knowledge bias).
• Often, work is divided into segments that a particular participant owns. Discovery and planning is owned by the PM and the designer. The developers own technical feasibility and implementation, while customer support is there as a heat-check, bringing their deep understanding of what’s happening on the ground from day-to-day.

So far, so good. Delegation of responsibility and a team with enough diversity in skill to build and release work that finds success.

Where things break down

1. Participants are involved selectively

Most teams these days don’t use waterfall methods (lord help you if you are). But even if you’re following a more agile process, it’s common to involve participants too late in the game. A good rule of thumb: if your process has anything that smells like a “hand-off”, something might be wrong.

I’m not advocating for unnecessarily large meetings all the time. That’s counterproductive. I’m saying participants need to be involved at key milestones so you can build shared understanding about the work. If major decisions are being discussed that impact work downstream, involve the participants that will be affected. This doesn’t mean everything becomes a democratic vote. It’s more about giving people the chance to wrap their head around the entire problem, digest proposals as they are being discussed, and make suggestions for improvement.

In short, talk with product team colleagues early and often.

2. Communication channels are selected for expediency, not effectiveness

For many people, asynchronous communication tools have become the default.

I’m not opposed to email or Slack, they are often the right tool for the job. But when something of nuance needs to be hashed out, it needs to be done in real time. I don’t care if it’s over Zoom or IRL, you need people speaking to one another with no latency.

The cost to resolving tricky problems over asynchronous communication tools is exceptionally high. Both in terms of time and quality of output. Just don’t do it.

3. An overreliance on words

The best teams I’ve worked with show, don’t tell. They use prototypes, imagery, diagrams, or other visuals to communicate ideas. A picture is worth a thousand words after all.

The most comical example of this is when a group of people are discussing a particular problem in a product. Rather than just show the problem via screen share, they describe it while everyone else tries to envision it in their heads. Madness!

4. Editing and curation matters

Communicate only what is necessary for your audience. Be merciless in your editing.

Our attention spans have steadily worn down over the past decade thanks to changes in how we consume media. Someone that’s consumed short-form internet content for the last 5 years is going to struggle to read a 2000 word Jira ticket with no headings, paragraph breaks, or structure to speak of.

• Break communications into discrete chunks when possible.
• Write sparingly, with a focus on intent and outcomes.
• Use lists and tables.
• Eliminate all boilerplate.

Fight the urge to regress

I believe many of us already understand the problem listed above and how to avoid them. That’s the easy part. The hard part is fighting the urge to slide back to the defaults.

• “I don’t need to involve the developers in this discussion, they’ll figure it out when the time comes.”
• “I’ll just email this question rather than talk to her directly.”
• “I’ll just dump this into the ticket without editing it for clarity.”

For those of us leading product teams, it’s crucial to fight the urge to take the easy path when working through big problems. The path of ill communication may be convenient, but you will pay the price over the medium to long term.