Make your development team happy with better communication

Communication is hard. We pay a lot of lip-service to how important it is but don’t talk a lot about getting better at it.

People who are good at things have a process for doing them. One model you could employ to make your workplace communication is hourensou.

This comes from three Japanese words:

• Houkoku (報告) — Informing. Giving your manager a high-frequency stream of data about everything you do.
• Renraku (連絡) — Reporting. Making sure everyone whose job depends on your work knows what they need to know.
• Soudan (相談) — Consulting. Seeking out people to pool experience/knowledge, address concerns, and build consensus.

Take the first syllable from each and you get hourensou.

The concept of hourensou comes from hierarchical Japanese management style. The translation of the original Japanese concepts are steeped in this culture, so you might not consider it applicable to companies with more complex org charts.

With a bit of tweaking however, we can apply it to individual developers on a team.

Communication on development teams

We talk a lot about getting our development process just right. We have hundreds of conferences about “Agile” development, certifications, and armies of consultants each claiming that they know the one true way while charging ridiculous daily rates.

As an individual contributer on the team, you can’t change the process. Your ability to influence how others behave is limited. You can however make yourself a good node in the communication graph.

Hourensou is a quick and cheap model that you can implement to do this as an individual. It requires no buy-in from your manager. You can do it on both high-performing and monstrously dysfunctional teams.

Here’s how it works:

• Reporting — The firehose of your activity. If you’re using hosted services like Heroku, GitHub, Trello etc, you can bring notifications of all of your activity together in email or in a Slack channel. You can give a quick summary of what you got done in a given day in a small update, perhaps using iDoneThis, but a quick message over IM/email will do. Goal: Anyone invested in your day-to-day work can dip into and out of your activity stream as they see fit.
• Informing — Summarising information to do with your work and sending it to people who need to know. This can be using comments in your issue tracker, via IM, email, in-person conversations or any other method of communication. Goal: Anyone who’s effected by the work you produce has the information they need to do their job.
• Consulting — Seeking out feedback and opinions from people who will be affected by your work. This could be asking about requirements in comments on your task tracker, sending emails to ask for feedback on delivered work or any other interaction where you’re eliciting feedback rather than broadcasting information. Goal: Minimize the number and magnitude of surprises about your work.

Make hourensou a set of habits.

Who on your team could do with having access to your activity stream? Set that person up to see the stream with whatever communication tool you use at your company. Try writing a daily update on how you spent your time and what you’re planning on working on next.

Ask yourself if there’s anything that you’ve discovered or realised today that other people need to know. Is the work you’re doing taking longer than expected? Your manager would probably like to know that sooner rather than later. Would your clients benefit from clear instructions on how to demo a feature you just shipped? That would make testing out your delivered software far less error-prone.

Whenever you make a decision about your work, ask yourself who might want to be consulted about it. Who’s feedback would it be worth eliciting to make sure the thing you’ve delivered is the thing that your organisation actually wanted.

Build a daily checklist for yourself. The details aren’t important, but having a checklist that you follow consistently ensures that communication is never more than a day too late.

Here’s an example daily checklist:

* [ ] Log major activities via iDoneThis
* [ ] Spend 30m responding to emails
* [ ] Inform X, Y, and Z of new developments in project A
* [ ] Mention any deployments to P in QA so they know to check them

This system may sound like over communication but over communication is a good thing. No developer was ever fired for being too communicative. Build communication into your daily schedule and you’ll deliver better work, be more valuable to your team and ultimately to anyone you ever work for.

- Najaf Ali

P.S. We’re Happy Bear Software. If you’ve read this far then you should probably sign up for our mailing list to get regular updates from us. No spam, and you can unsubscribe at any time.

Originally published at www.happybearsoftware.com.