This earlier piece has stimulated some memories, not all of which are pleasant ones...but which I feel I should recount even so. In part, that’s because the subject – competence – is important, but in equal measure it’s because I want my Gentle Readers to know the relevant stuff about the guy who writes these sententious, often contentious pieces.
First, a brief vignette from the early Nineties. It was December, the day before our Christmas break, an interval of paid holidays that spanned Christmas and New Year’s Day. My employer was wise enough to realize that nothing much gets done over that period, and preferred to close its buildings rather than pay to keep them pointlessly open. Most of us looked forward to that interval...most of the time.
I was straining to find a problem in one of the most difficult pieces of work I’d ever undertaken. Without going into gory detail, let it suffice to say that no one else in the company was equal to the task. As our story begins, I wasn’t sure that I was, either.
Closing time was approaching, and there was little work and general jubilation. I wasn’t part of that. The problem I was focused on occupied the whole of my attention. It became obvious as time passed that I wouldn’t crack it that day. Unhappily but resolutely, about half an hour before we were all supposed to vamoose, I informed my supervisor that I’d need building access over the Christmas break.
He was stunned. He called his supervisor, who was equally stunned. That worthy called Security to arrange to have the building kept heated, lighted, and guarded – yes, it was a defense contractor – and the Security people were stunned...and very unhappy, as that meant that one of them would have to be there with me. They called my supervisor to quarrel with my request.
My supervisor put his phone aside and asked me, very gently, whether it was really necessary for me to continue through the break.
“I have to,” I said. “If I don’t crack this now, I’ll lose the thread. That might mean missing the deadline.”
“Can’t you leave yourself notes?” he pleaded. “Security wants this place cold and dark by five.”
I just stared at him. He wilted, picked up the phone, and told Security in his don’t-test-me voice that there was no option, it was vital that I be there the following day. (I have a very effective stare.)
All’s well that ends well. I was able to crack the problem the next day before noon, thus sending an only slightly disgruntled Security officer back to his family and freeing us both to enjoy the rest of the break.
Yes, I was competent enough to solve the problem, but more important yet, I was committed to solving it, in time and within budget. Everyone else in my chain of command would have let the matter slide – missed deadlines in defense contracting are more common than the ones met – but I wouldn’t have it. I’d committed myself, which put my reputation for always being on time on the line. I was determined to make it come Hell or high water.
This second, less pleasant memory comes from just a few years ago.
A program developed a few years prior to my involvement with it had gained favor with projects other than the one for which it had originally been developed. My supervisor asked me to see if it could be adapted for more general uses than its original, narrow focus. I agreed to do so. Unfortunately and most unwisely, he took that as a commitment to making it so, and told those other projects to expect a version for their use Real Soon Now.
The program under discussion:
- Was in a language I didn’t know;
- Required a toolchain I’d never used;
- Used third-party libraries I didn’t know;
- Was undocumented and completely uncommented;
- And all the original developers had left the company.
I couldn’t even get the BLEEP!ing thing to run, much less begin to probe its structure and what bound it so tightly to its original focus. After a few weeks’ struggle, I went back to my superior and reported my inability to get anywhere with it. He was stunned – and well he might be, as I’d never before admitted to defeat by anything. Then he proceeded to stun me:
“You have to make it work,” he said. “[Another project] is expecting it by the end of March.”
I restrained my temper by a very narrow margin. “I didn’t commit to solving this for you,” I said. “I said I would look at it. I have, and I can’t get anywhere with it. There’s just too much I don’t know.”
“Well,” he said, “what do you need?”
“Someone who knows the language and the toolchain, at least,” I said.
“I don’t have anybody I can give you,” he replied. (He had sixty software engineers reporting to him at that time, yet I was sure that was true. We were very tightly scheduled.)
I summoned my reserves of resolve, which were rather low at the time, and said, “Then I can’t commit to this. You’ll have to tell [the other project] that it’s a research problem.”
(“A research problem” is what we call any ball-of-yarn undertaking where we have no idea whether it can be done, much less how soon or for what budget.)
I felt bad about saying that. For one thing, I was the company’s top software guy, and I’d never failed at anything before that. For another, the desirability of the endeavor was very high; we could milk a lot of revenue from it. And for a third, I genuinely liked my supervisor and hated to tell him no.
But I couldn’t commit to a project with a fixed delivery date when I was so completely incompetent in so many of the required areas of knowledge.
Once again, it ended well. My reputation was sufficient to move the immovable: my supervisor “shook the tree,” found in another department someone familiar with the language and toolchain who could assist me, and together we cracked the mysteries of the program and found ways to generalize it sufficiently. However, the larger point here is what matters. Knowing that I wasn’t competent to solve the problem alone forced me to withhold any commitment to it. My chain of command, realizing that I was only reporting the facts of the matter, acquiesced to my needs.
It’s impossible to squeeze blood from a stone. If you can’t, you can’t, and there’s no honest, responsible way to avert the admission. You have to be willing to say “I can’t,” and / or “I need help,” and stand your ground. Yes, it’s about appropriate humility, but not entirely so. It’s part and parcel of your personal integrity: your commitment to the truth.
For there are higher and lower commitments in life, and the acceptance of that fact is essential to anyone who puts himself at the service of others. You must be ready to recognize and bow to a higher commitment even at the cost of admitting to the limits of your competence. If you’ve never been there before, it can be an occasion for personal embarrassment.
In a commercial context, the highest of all commitments is to an old maxim of conduct: “Don’t make promises you can’t keep.” But truth, including the truth about oneself, matters just as much in any other interaction with other people. You must never, ever never, ever say “I can and will” if there’s an appreciable chance that you can’t or won’t.
The admission of one’s limitations is essential to the concept of competence. Yet far too many persons in far too many walks of life are unwilling to do so. It’s too great a blow to their “self-esteem.”
“Vanity. Definitely my favorite sin.” – Al Pacino, as Satan, in The Devil’s Advocate.
Occasionally it is scary how parallel our careers were. I had almost precisely both of those experiences.
ReplyDeleteThere is no animal more committed than a good software engineer. And, it must be said, no animal more likely to be committed than a good software engineer.
Been there, done that - would have gotten the T-shirt for it, if they had the humility to make one...
ReplyDeleteThe last place I worked had a love/hate relationship with me:
They loved that I was the best troubleshooter they'd ever seen, and hated that once I latched on to a problem, it was very difficult to get me to let go of it - short of solving it.
It made for an occasionally frustrating tenure there...
". . . (I have a very effective stare.)"
ReplyDeleteThe high point of my day so far! :)