Remember back in the days of prohibition when a person wanted a beer they had to know the secret knock to get into the backroom of a club concealed by a false bookcase? Me neither. I’m talking about permitted bootlegging in the business sense of the word.
As I mentioned in my bio I spent 8 or 9 years of my career managing a team of developers. One of the first policies I implemented as a manager was permitted bootlegging. I encouraged every one of my developers to spend 10% of their time working on a software project of their choice that had nothing to do with the standard product we were building. I got the idea from my dad who worked for 3M. Software Developers can be odd ducks (to other people – us developers think you are the odd duck) and like most development organizations we had several kinds of developers. I’m going to use a broad brush and group them into 3 categories.
We had people that insisted on pounding out code 12 hours a day 7 days a week. These folks could do amazing things in short periods of times. They could get a late project back on track or whip out a feature in no time. It is a luxury to have one or two of these people on your team as nobody can reasonably ask for anyone to work these kinds of hours. The difficulty in managing this sort of person was if you pointed them in the wrong direction look out! They were a bit like rhinos in that they would very quickly blaze a trail through the code base doing all kinds of “damage”. Check in with these folks early and often to make sure they are doing what you think they are doing. They don’t like to undo hours upon hours of work because of a miscommunication and who can blame them? It is also quite a challenge keeping them busy. We’ll call this group the rhinos.
Another group of developers wanted to be told exactly what to do, when to have it done, and to be left alone. They will let you know if they have a problem and won’t tend to try to move forward with something they don’t understand – it is just not in their nature. They don’t care too much about what they are assigned to work on as long as it is in their comfort zone. These are the people that can tend to fly under the radar so make sure and share credit for your success with these folks. You need a lot of these people on your team. We’ll call this group the workhorses.
The final group of people I want to talk about could probably best be described as the mad scientists. These are the kinds of people that are not happy unless they are challenged. These are the folks you want working on critical parts of the framework. You would go over a problem with them in painful detail and turn them loose. They would disappear into their dark laboratory only to return days, weeks, or months later when they were done. Schedule means very little to these folks because…well…it is not done until it is done! You want one or maybe two of these people on your team but you can not afford more – you’d never get anything built. The challenge with managing this type of person was that it was hard to schedule their activities and you don’t always have an interesting problem for them to work on. Let’s call this group the Einsteins.
By way of an apology for pigeonholing these good people I will admit that the personality of every individual I managed really fit into all 3 of these groups to one degree or another (well maybe not the Einstein group). My job was to figure out a way to get this crew to build software. I had to ask the Einsteins to write mundane code, I had to keep the rhinos from running further ahead than we could test, I had to ask the workhorses to do work they weren't comfortable with. So how do I keep the Einsteins challenged when they are doing mundane work, how do I keep the Rhinos out of the code during the definition phase and how do I get the workhorses to get comfortable doing something they have never been asked to do before? That is where bootlegging comes in.
The role that bootlegging played for the Einsteins was that it kept things interesting all the time. I never had to encourage these folks to spread their wings and learn something new. I used bootlegging as a way to keep them from leaving the company. They knew that, I knew that, they appreciated it, and most importantly they never left the team. For the rhinos I used bootlegging as a way to keep them busy during slow times. At the end of the day what drives the rhino is they just want to be busy doing something useful. Their bootleg projects were usually related to productivity tools. Tools that made the development team more productive but had nothing to do with our product. Workhorses were not wild about bootlegging. I would really have to push a project onto a workhorse. I would try to recognize a new technology or feature coming up in the project and use the bootlegging task as a way to introduce them to it. To be honest, the bootleg projects didn’t mean much to these folks but it was always there if they wanted to use it.
As a manager I was very proud of the fact that I never had a developer leave my team to join another team. I think giving each team member the freedom to work on whatever software project they wanted with 10% of their time was a big part of it.
