Scaling Development Teams: The Whiteboard of Truth
I’ve spent a fair amount of time as a development contractor working in teams that are getting bigger, rapidly. I’m often brought in to help with development when a big round of funding has been raised and the investors need to see progress, or when a new client has a tight deadline. So, I see a lot of the problems that are associated with scaling teams quickly, and I thought I’d share some thoughts on making that process easier. Firstly — whiteboards.
When the time comes to increase the size of your development team, there are lots of tools you can make use of to help the process. Issue tracking software can organise everyone’s work and report on progress, a wiki will help new team members find answers quickly.
Before you bother with any of that, though, I’d suggest you buy a whiteboard. Ideally the largest whiteboard you can fit in your office. It’s very simple, but often overlooked. In my first job as a developer at a startup we had to campaign for months to get a whiteboard, but it really is the best present you can give a growing development team.
A whiteboard gives your team somewhere to draw big pictures of how they plan on doing stuff. It gives discussions a focal point, and encourages people to talk to each other. Talking out design problems is a really good thing, but a whiteboard can also help with a less obvious problem.
When a team grows in size over a short period of time there is inevitably friction. When two developers meet they generally have a habit of sizing each other up, like when cats meet for the first time. The usual outcome is that both developers conclude the other one is dangerously incompetent. I’ve done this many times, and I have often been wrong. In this state of mutual loathing, team members will form friendships with those they consider to be the least incompetent. They will whisper about how awful that other developer is. Software gets built, managers stay happy, but tension is building.
Then one day someone books some annual leave, or has to come in late three days a week because their child-minder quit, or goes on a training course, or causes some other disruption to the usual working pattern. Now they are regarded with increased suspicion. They are not pulling their weight, they’re slowing the team down. They are a liability. Morale drops, productivity falls.
Of course, in most cases, this is nonsense. They are simply a human with one of those human problems that humans sometimes have. So if one of those human-type events happens, or any other even that might mean someone’s location isn’t immediately obvious, write about it on your whiteboard.
“Bob on holiday, 1st-9th June” “Matius coming in late on Wednesdays”
“Alice at a conference 3rd-4th May”
Note that you don’t need to write “John going to the doctor to get that strange rash looked at” or similar. If the reason for the event isn’t work related then no one needs to know it, they just need to know that person has a genuine reason, and that the boss is aware and okay with it. Without this kind of transparency on people’s working patterns there will always be the potential for friction. It also helps people plan their time better — if they know that the person they need will be out of the office tomorrow then they’ll go and talk to them today.
I call it “The Whiteboard of Truth,” and I think you should too.
Jez Halford is a software development coach helping teams in the UK to be more agile, scale better and automate more. Visit jezhalford.com to find out more.
