The Art of Losing

I lost an argument yesterday.

Essentially, I proposed "to-may-to," a peer countered "to-mah-to," I rebutted with some additional facts, and the boss chimed in with "I like to-mah-to."

My first instinct was to rebut again and make my points again but stronger. But my experience and executive overrides kicked in and I reminded myself of an old adage "Before you can influence others, you must first allow yourself to be influenced by them." This has led to my own adage: "Never squander an opportunity to lose an argument." Losing can be good; it gains you equity with the team if you do it gracefully. Here are some points that help me when I need to lose (or when I'm going to lose anyway).

1. Any time you disagree with another expert, there is a 50% chance you are wrong.
2. Even if you are right, any time you disagree with an expert, there is a 50% chance that what you're arguing about has no practical significance for the user.
   
   Let's stop there for a moment. That means there is only a 25% chance that if you continue an argument and win, you will do any good. I think point #2 is generous in assigning a 50% probability that there is any efficacy in the outcome. If two experts disagree, either proposition will probably work. Think about the bottom line impact some of these disputes have or don't have. The answer should be a gauge as to how long the argument should go on. For example, how much will your company's profitability be affected if you use "e-mail" or "email"  in the UI? In this example, flip a coin but don't flip it too high. Every second you wait for it to land is losing money.
   
   
3. Give the other side the last word. Losing with an "OK, but..." forfeits any equity the loss would have gained you.

Here is the truth that took way too long for me to learn. Your value to the company (and your likelihood of surviving the next layoff--and yes, there WILL be a next layoff) is not determined by how smart you are perceived to be. It is determined by how effective you are perceived in facilitating other people doing smart things.

Truth is, most people do not remember who made specific points in a meeting. More times than not I hear the wrong person being credited with a particular statement. What people will remember, however, is how well the teams you are on end up doing.

Don't seek a reputation of being the "guy with the answers." Instead, become the "guy who initiates and facilitates productive conversations."

And many times that means both making the initial proposal and then graciously losing the argument that ensues.

If I weren't so naturally talented at making the wrong proposal, I'd probably have to do it on purpose just to get ahead.

Outliers and Parallelism

Sometimes we tout parallelism with the same misguided religious fervor with which we persecute any use of the passive voice. For example, I am not the least bit bothered by the lack of parallelism in the following menu (nouns and verbs mixed):

That having been said, it is a pretty powerful force. And sometimes we must choose between being parallel and some other good rule of rhetoric.

Two examples that vex me periodically:

• Tables where all of the cells in a column have multiple entries except one. I want to use bulleted lists to make the multiple entries more readable. Do you  bullet the lone item in the one odd cell? I do.
• Grouping fields on a form where inevitably there is one field that accounts for an entire function and doesn't go with the others. Do you fence in the one lone field with a grouping box or leave it out there as a free range field? I fence it in.

Am I being overly zealous in my desire to have parallel treatments? Are there other examples that vex you? Chime in.

How I spend my time

I'm not saying...I'm only saying.

On Nudging and Fudging

I went to an interesting TAG (Technology Association of Georgia) Product Management breakfast meeting last week, and I participated in a buzz group that talked about Agile and Product Feature road maps. It was interesting that nearly every company/person in the session had the same experience about how to manage executive expectations.

Executives are focused on dates, much more so than features. Don't miss a date! But what you CAN do is get flexible with the feature set that releases on that date. Or if you like pithy rules: "Don't nudge dates; fudge features.

Now customers are a different thing, and they pay more attention to features. The collective wisdom of the group was to commit to only 80% of your capacity so you had some bandwidth to fix problems or accommodate late entries into the requirements mix. Some also had quarterly communications with customers to let them know what would be rolling out in the near future.

Another interesting nugget from one company was to let product managers communicate only with prototypes and not bullet points. It made sure that PM was talking about things on the "Do" list and not on the "wish" list.