My Secret Job Title is “Code Butler”

I have been undergoing a paradigm shift in the role of a software developer. My new guiding metaphor is "butler." That is, in all my interactions with the employer, I ask, "What would a butler do?" The litmus test for good interactions with an employer (and with coworkers) is, “Would a butler do that?” The guiding axiom is that a butler’s job is to take work from their employer not to make work for them. Here are some slogans:

A code butler expresses concerns and then lets go.

A code butler avoids requesting specific tasks.

A code butler gets paid to think within assigned domains.

In each case, there is a parallel to being a butler. Would a butler argue with his/her master if the master asked for something? Would a butler request to have kitchen duty instead of yard duty? Probably not.

There are times when a butler should be more assertive. If the butler has reached his capacity, the master needs to know. "Sir, I appreciate that you would like me to do task X, but I am already at capacity with task Y.” Or, if the master asks a butler to do something against his moral principals, the butler could resign. "Sir, I'm afraid that if you require me to do <some reprehensible act>, I will choose to resign as your butler."

In many cases the choice of whether to speak up is ambiguous. “Do I push back when the master asks me to shoot her in the foot?” Maybe there are good reasons that we do not understand. This ambiguity is the spice of life and asks us to draw on our full intelligence to choose the most butler-like action. Our response to the ambiguity defines our butler-style.