I’ve worked for large companies from both the UK and the USA, and they all loved making their staff watch training videos about “standards”. The UK companies’ videos were mostly about financial regulations, health and safety, and things like that. The American companies though, took a slightly more “intense” attitude. Their videos were about the danger of talking to people who may be on the list of people banned from trading with the company, the perils of bribing foreign officials, and people who never took their vacation. This might strike you as odd; after all the rest of the world doesn’t usually think of US companies forcing staff to take all of their vacation allowance, but in this case they were making a point of it.
After all, their reasoning went, WHY would someone not want to take vacation? Once they had mentioned this, they started talking about staff not letting people know what’s going on in general and paying invoices from companies you’ve never heard of, and it all became clear: people who seem afraid to be away from the office and who keep things to themselves may be, according to this training video, indulging in dubious activities.
Obviously this was more related to finance departments, but I’ve seen similar things happening in Development or Engineering departments. Not the dubious invoices of course, but people who wouldn’t say what they were doing. They never refused outright, but they were always very busy and things would just “get done”:
A bug in a mysterious part of the system? “Oh, I just fixed that as we were talking about it,”.
A scheduler change? “I’ve just done that one,”.
A remote device having problems communicating with the rest of the system? “No need to add a task to the backlog – I’ve just made the change to it and restarted the system,”.
Need a report? “I’ve just run it against production – it should be in your inbox now,”
Initially, this seems like a really good thing – these people are being responsive and things are happening almost before you ask for them. What could be wrong with this situation? Everyone’s happy and we’re all being productive and agile.
Like so many other things, that seem like really good things, this is NOT a good thing. It is in fact a very BAD thing.
About now you’re probably wondering why I’m raining on what looks like your very productive parade, so I’ll explain.
There are two main reasons “busy” developers are a bad thing. The first is this metric:
or maybe:
This metric has numerous names, but depending upon your culture, your staff probably know it as the team’s bus or truck number. Put simply, it’s the number of team members who could be hit by a bus (or truck) before your company is in serious trouble. In an ideal world, this number is as high as possible but, by hoarding information about your systems, not properly documenting the way to change or update them or by just not keeping track of changes they’ve made, the “busy” developers are working to reduce your truck (or bus) number.
If you’re still not feeling worried by this, run through this little thought exercise: Your “busiest” developer, who fixes everything, gets hit by a truck on their way to work. How much trouble is your system in? How about if the next busiest makes it to work, tells you they’ve won the lottery, and what precisely you can do with your job before walking off, never to be seen again? Are you worried yet? What if several of your developers are in a lottery syndicate that wins?
I’ll mention at this point that I’ve not seen any of these things happen yet, but I used to work for a company that provided “Key Man” insurance for just such occasions, so if actuaries think it’s likely to happen I tend to trust them.
Not wanting to pile on now that I’ve brought the truck number to your mind, I’ll mention the other reason busy developers are a bad thing anyway. Maintainability and traceability. If you’re working in a regulated industry like finance then someone, at some stage, is going to come asking questions about your system. Even if your industry is unregulated, how are your developers going to keep track of the state of each machine in your system? What happens if you deploy a software update across your fleet of machines, and suddenly many of them stop working, because their settings were customized and not recorded?
So, what can you, as a manager or team lead, do about all of this?
- Make it clear that anything that happens to the production system MUST have been tested in the development and test environments first. All changes must be documented as a task, story or ticket, depending upon how your department works.
- Fleet devices must run identical software, with separate, independent, custom configuration if required. Updating the software should not change the configuration. Redeploying the software should not damage the configuration.
- Remove the ability of developers to make changes to the production systems. A separate team should be responsible for deployments and, if that’s not possible, access to make changes should be enabled for deployments and then disabled when they’re finished.
These three changes should be enough to correct most of the problems with your “busy” developers, with one exception: the culture that promote this sort of behaviour in the first place. Without changing that, things will gradually creep back to the way they were, and you’ll have achieved nothing.
That covers the management side so, as a software developer, you need to remember these two things:
- You’re a professional, act like one! Let people know what you’re doing – don’t hide your activities.
- Take all of your vacation!
