The head of Project Badger (at the much larger company that bought it a few years ago) recently moved on to other duties in the company. We talked briefly just before he did, and he said that he’d learned a lot from me.
I was startled, but I figured that was just a stock corporate-speak phrase he was using with everyone. It didn’t seem there was anything that I (primarily a hobbyist-turned-professional software developer) knew that would be useful to someone like him, a corporate manager. But later I got to thinking about it.
When we first sold Project Badger to that company, I had to adapt quite a bit. I’d never dealt with a large corporation before, and didn’t understand the culture. I thought the Dilbert comic strip was an exaggeration. It is, but not by much.
For example, soon after we sold it to them, they asked us to embed their help-line 800 number into one of the error messages. Several months later, a customer who got the message actually called the number and got a big surprise — it was a phone-sex hotline. It turns out that the phone number they’d given me was wrong in one digit.
It was a simple and innocent mistake, and one that was easily corrected (though not quickly — there were a lot of products incorporating it by that time). But I watched in amazement as they assumed that it was deliberate attack on them, and paranoidly tried to find some conspiracy. No doubt they discussed whether we were working against them too, though they didn’t let us know that. I hadn’t noted which one of them had given me the number, and after several months I couldn’t remember for sure, so they were looking cross-eyed at each other too. I know corporations have to be concerned about that kind of thing, but they took it to a ridiculous extent. My feelings are plainly read on my face (I’m no good at poker), so I’m sure my stunned amazement showed; maybe it helped show them how badly they were overreacting.
As another example, different people would load a different project onto a single person at each meeting, and a few days later ask why this task or that one wasn’t done. It was just like college, where each professor assigned you enough work to keep you busy until the next class, deliberately ignoring the other classes you were taking. It was ludicrous, and no one seemed to be able to see that it was a problem, let alone do anything about it.
I can only concentrate on one thing at a time, so I came up with an aikido-style solution: whenever someone tried to give me a new task, I would agree to it, then immediately ask that person to clarify which one was the priority, the new one or the one I was working on already that was assigned by person X. If they felt that they had the authority to override person X, they could give their project priority; if they didn’t, then they would realize that their project was on the back burner. Whenever anyone started playing the blame game, or confronted me about not having something done, I could give a logical and air-tight reason for it, and one they couldn’t argue with. I think that earned me some grudging respect.
Then there’s e-mail. When someone asks for my analysis of a situation, I assume they want to know it, so I try to give them the whole thing. I quickly learned that when I did so, the management people didn’t bother reading it — they wanted a quick yes or no answer. So after writing my full analysis, I went back to the top and added a one- or two-sentence “executive summary”:
Subject: Preventing the sharing of licenses
Executive summary: don’t do it, it would cost us more, irritate our legitimate customers, and do nothing to stop the abuse.
Long answer:
> This is an old subject that for some is unpopular, however this
> addresses the problem of customers sharing their keys with contractors
> and associates despite the fact that our EULA specifically forbids it,
> and I think it’s time this was addressed. [...]
Sorry to do this, but I have to disagree.
[Long analysis with example follows.]
The management people could quickly see the results, and members of the team who were interested in the reasons behind it could see that too.
I’m not even going to dig into the culture of having hour-long meetings about even the most minor things, and requiring the developers to attend them instead of getting any development work done. I’m sure I stepped on more than a few toes while getting that straightened out, but I can’t apologize for it; it’s a ridiculous practice, and a waste of valuable programming time.
So in the end I think he was telling the truth: he did learn a lot from me, and I just didn’t realize it at the time.
