Projects that are executed against the will and without the knowledge of the management are a particularly fascinating artifact of the software engineering world. The English term I heard used for these is “Skunkworks”. However, I particularly like the German expression for such stealth missions: U-Boot (submarine). Nobody is aware of the U-Boot until it suddenly surfaces. How is it even possible that this kind of insubordination exists in our industry?
In DeMarco’s classic “Peopleware, Productive Projects and Teams”, the phenomenon is described as follows:
Skunkworks implies that the project is hidden away someplace where it can be done without upper management’s knowing what’s going on. This happens when people at the lowest levels believe so strongly in the rightness of a product that they refuse to accept management’s decision to kill it
Peopleware, Tom DeMarco and Timothy Lister
So the typical setup for a U-Boot is the following: An engineering team feels strongly about a particular project. Upper management takes the strategic decision to cancel the project (or to not even start it). The engineering team then disregards that decision and goes ahead anyway. At some point the project is released into the open, presenting the rest of the organization with faits accomplis.
The first obvious question is how it is even physically possible for a project to be executed in this manner.
We live in an age where cases of people are known that outsource their own work or that work multiple full-time jobs at once. Against that backdrop, it does not seem that crazy to think that a team could get away with flying under the radar, building something that nobody is aware of.
A second factor may be a hands-off management approach which is considered a productive strategy in many engineering organizations or a front-line manager that turns a blind eye. Due to the nature of software development work, upper management has no way of seeing any difference in the actual behavior of the team in question.
Third, I have only witnessed minor small-scale U-Boot missions myself and in each case, they came with an investment of the personal time of the engineers involved. This makes it harder to detect the project and more difficult for the organization to punish the insubordination. After all, they are getting a good deal on the result.
Lastly, a U-Boot by definition removes all the heavy processes and most of the politics. No project management, no status meetings, no people to keep in the loop. I would estimate that, depending on the organization, this can at least cut in half the time investment required for project completion making that hurdle easier to cross.
How should we understand the fact that this is a phenomenon frequent enough to have a name? I would argue that it shows two things:
Firstly, we are an industry full of incredibly passionate people who care so much about their creations that they are willing to take considerable risk defying a direct order.
However, secondly, it also demonstrates a widespread lack of leadership. There are only two options: Either the management decision to kill the project was correct given what was known at the time or it was not.
If it was wrong, then that demonstrates that the engineering team had information that did not make it into the decision and the team did not see an opportunity to speak up. If they did speak up they were not understood. In any case it is a sign of a broken communication channel.
If the decision was right then it is the other way around and the critical information did not reach the engineering team. You don’t give orders to passionate and intelligent people but you win them over by presenting a good case and most of all by understanding and genuinely considering their input.
If you try to impose a command and control structure on the average software organization, you should not be surprised to see U-Boots popping up left and right, at least until all the passionate people have left.
The Solution Space 
Leave a Reply