Sometimes you actually do have to be cruel to be kind
My kung fu teacher Andy, who was recently promoted to 6th degree black belt in Icho-Ryu Aikijutsu, said something the other day that really hit home to me.
He mentioned that unlike Aikido, which tends to strive for harmonious resolution to problems, Aikijutsu is a very brutal art. Aikijutsu fighters practice horrifying techniques that maim, blind, kill, or otherwise tend to void the warranty on the person you are fighting with.
The Sacrifice
The sacrifice is a strategy that is meant to be used in situations in which you are dealing with multiple opponents. The idea is to grab the first person you can and execute the goriest and most horrifyingly over-the-top technique you can on them. The specific example he gave was to break the person’s arm in a compound fracture and then drive the stub’s bone fragments into their torso.
The point is to let the rest of the group know exactly what they are dealing with and hopefully give them second thoughts about continuing the altercation.
This sounds like bloody bravado, but the reasoning is that you are in fact sacrificing one of the group so that the others will break off from the fight and survive the encounter. You are killing one person in the hopes of saving the rest of them.
While I personally don’t think that I have the chops to be that considerate (I fight like a kitten) the message struck with me, and I immediately saw not only how it applied to business, but how I myself had screwed up and let a team down by failing to make such a move when it could have made a difference. I feel that people that I care about are paying for that failure now.
The point here: sometimes you have to do something horrifically bad to save yourself and others.
Sacrifice Moves in Business
Let’s say that you are working with someone in a tech company, and that they are a reasonably good free electron. Unfortunately, they have taken on a pet project and that project has reached the point where it is their answer for everything.
I am not speaking in the abstract: I know of one case in which one engineer was required to develop an config file-based technology that would allow customers to easily customize their information retrieval product. The engineer became so enamored with his proprietary approach that he began to move beyond simply layout customization and started defining actual programmable logic within his system.
The result was a hideous mess. The file used by the customer became a very large, arcane system of APIs devised by the developer. All binding was done dynamically, including programmatic behavior, which made tracing the code incredibly difficult. Eventually the system became so non-deterministic that even the engineer himself could not easily explain or understand how it operated.
This system was the foundation for the company’s flagship product. As new requirements were added, the engineer would satisfy them by making his system even more complex, rather than simply writing implementations in regular source code.
An initiative was recently passed in which it was decided by the company that the system was too complicated for customers to easily modify them selves. The goal of the initiative was fairly simple: simplify the file format and make the system more modular in as timely a manner as possible. The company was working on a new release and the improvements needed to be done before the new development cycle started.
The engineer in question came up with a complicated solution: develop a new, more verbose syntax and macro expansion software package from scratch. He estimated that it would be up and running within two weeks. A few people expressed some concern about the idea, but he pushed back, saying that it was the most elegant solution to the problem, and that technology he was using was the most intuitive model available for non-technical users
This was the moment at which I should have made the sacrifice, but didn’t. The plan was, in my opinion, horrible: they were going to write new software to deal with a problem that had been handily addressed by tools like m4 for more than a decade. They were replacing an already extremely verbose syntax with one that was even wordier. They were effectively attempting to put out a fire by pouring more gasoline on it.
Why I failed
I failed because I was unwilling to be as big a stinker as I’d have to be redirect the project. I don’t believe that I could have made a strong case against the plan without openly denigrating him to the rest of the company. The idea was terrible, it had been historically terrible. His subsystem was the single biggest delay of every release in the company’s history. It was complicated, and many people felt (although few would step forward and admit it) that no one, including the developer, really understood how the system worked any more.
I felt that this was going to slip the project even further, increase its complexity, make the system harder to use, and introduce more bugs. To actually intervene and stop this from happening would have required that I go to the executive level and say “this person has seriously jeopardized your company’s survival, and here is why. Here is every case in which he has made a decision that has hurt you. He is making a similar decision now. You can not allow this to happen.”
To put it bluntly, I would have had to sacrifice the engineers self-esteem, and perhaps his job, in order to save the company.
And I couldn’t do that.
The Results
The results would be funny, if it wasn’t actually so tragic.
Estimated time to complete: 2 weeks
Actual time to complete: 6 weeks
Original input file length: 5,500 lines
New input file length: more than 12,000 lines
Despite the simplifications the file size more than doubled! The increase in verbosity of the syntax has resulted in a file that is further cluttered and no easier to understand. The engineer in question spent an additional month that could have been spent working on the new release tinkering around with his new toy.
I don’t think that this was my fault, but I definitely know that I could and should have spoken up. Unfortunately, my desire to see the company succeed was heavily outweighed by my desire not to be a jerk or alienate the engineer. If I had worked under the Aikijutsu principle of sacrifice I might have realized that sometimes you have to do some really unpleasant things in order to save everyone else. As Rands told me: “There’s a difference between being a prick and laying down the truth. Sometimes you have to be a prick to get their attention, but when they see the truth they forget about the prick part.”
I’m not thrilled with the realization, but it will probably change how I handle these situations in the future. I really want to get along with others and be liked by them, but I’m starting to realize that being nice can sometimes cause a lot more damage than just dealing with the problems directly in the first place.
