Happy Bear Software

Make your development team happy with better communication

Some spinach

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:

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:

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

Find this article useful? Sign up to our mailing list to get updates like this in your inbox every week. No spam, and you can unsubscribe at any time.
Give me the goodies