Benisms
A Working Collection

01Truth, Data & Useful Consistent Lies

Start here, because everything else in this doc assumes you already believe this one. If you're still hunting for "the truth" in your data, the rest of the sections will just feel like a list of exceptions instead of one consistent worldview.

There is no truth. There is just a useful, consistent lie.

Ask what time it is. Whatever you answer is a lie — the most correct answer requires a physicist and has a dozen decimal places, depends on whose clock, and depends on what you even mean by "now."

Ask where you are (you as defined by what? your nose), right now (define now), globally — anything less than GPS coordinates in three dimensions, to absurd precision, isn't "truth" either, and by the time you've nailed it down, you're no longer there. Now try that cosmically. Einstein only figured out some of that answer, and got a cool prize for it.

Other useful consistent lies live in questions like: who are you? What do you think? How does that work? Take "who are you" — Ben Honey Dad is what my daughter calls me. Her friends, and pretty much everyone else, call me Mr. Ben Honey. Uncle Sam has a different answer on file. My Navy drill instructor had a few that I still can't fully explain. Or take age — for the record, I celebrated the 21st anniversary of my 21st birthday so long ago that that anniversary is now celebrating its own 20th anniversary. But a age comes with its own host of legal and cultural assumptions before it even means anything. Feel better about "the truth" now?

The truth is an expensive illusion. Everyone runs on useful, consistent lies, mostly because they're useful and consistent.

Single version of truth. To the extent practicable, use only a single version of truth, which is itself a useful, consistent lie. When there are multiple versions of truth, call it out. For example, with CPU metrics in a virtual environment, the virtual manager might say a device has CPU utilization of 40% for a given time slice; for nearly the same time slice, the agent inside the virtual device might say utilization is 37%. Each is a useful, consistent lie from the point of view of its source. Call out which source you're using, and try to refer back to the original data source rather than a summary of a summary.

Data → Information → Knowledge → Wisdom is not linear. It gets bent at every step by bias, data errors, misinformation, and outright lies. More data flowing in doesn't guarantee more wisdom coming out. Think of the telephone game. Get from the origional source and acknowledge the lie.

02Suck Less, Fail Faster, Technical Debt

The art of Suck Less is one of constant incremental improvement. Generally, making something suck less today than it did yesterday is a good day. Fail Faster suggests that methods, tools, and techniques being used against a problem that aren't likely to succeed should be abandoned sooner rather than later. Technical debt is all the loose ends and "good enough" solutions that infect the product.

A direct example of suck less: Develop solutions by getting a result, any result. Then mature that into getting a result you can control (turn it on or off, increase, decrease, etc.). Then mature that to get a result you want (formatted number, colored indicator light, etc.). Then apply that to the situation, keeping in mind the mature final solution. It's a mistake to attempt the mature final solution first. Build to it, iteration after iteration.

Leads to fail faster: recognize that the script or program above was excellent for defining the edges of the problem and control services, but rather than polish that script to perfection, fail fast suggests you refactor what you now know into a more effective method, keeping in mind the mature final solution.

Fail faster also includes throwing out what you have — that is, what's not working or won't mature into the final solution — and starting over. Nothing is wasted; you now have better definitions, understanding, tools, techniques, and clearer direction.

"Wealth Secrets of the Rainforest," featuring Michael Q. Pink, has an interesting take on this — specifically the Orchid Element (marketing):

1. Eliminate the unnecessary (eliminate all activity that doesn't contribute to your primary assignment).
2. Automate the mundane.
3. Delegate the routine (don't make the mistake of delegating things you should have eliminated or automated instead — if you think you can't afford a virtual assistant, either you don't understand the value of your own time or you have no value to offer; which is it?).
4. Designate your work (mark out strategic planning and execution as your primary focus).
5. Procrastinate the undefined.
6. Separate to cogitate (try working when others aren't, then relax when they are).
7. Motivate to intensify (an intense burst of activity over a short time to accomplish a strategic objective).

Ask of anything you're doing: is this consistent with my primary purpose, as I understand it? Does it contribute to the vision I'm working toward? If so, is it more important, more strategic, or more timely than what I'm currently working on?

The risk is that technical debt builds up. "Strategic initiatives that rely too much on manual actions quickly become elephants weighing down rather than enabling progress." Use brute force in the early stages to show a result, but stay mindful of being able to automate the process and integrate it into the overall workflow.

One way to suck less is to give yourself permission to use different models. Mr. Teman Cooke throws out the classic scientific model for something else, and makes a good case for it. Expand your tools and techniques. I have an example of using a new tool at Quest for Actionable Intelligence and Actionable Intelligence Lifecycle and the Conscious Use of Conceptual Models. Take the invitation. Teman Cooke, Ph.D., on abandoning the classic scientific model (identify a problem, research, hypothesis, experiment with independent and dependent variables, analyze data, draw conclusion) in favor of the cycle of scientific thinking instead (observations, questions, model or hypothesis, answers, prediction, test): "If you're truly lucky and get it wrong, that's going to bring up more questions, questions that require more explanation, which leads to new predictions, and so on, and so on, and so on."

Academic truth is not always practical. Useful to keep in mind, especially for fail fast. Academic truth, other people's truth, should help your understanding — but don't be afraid to take your own path with that understanding. Review the references, adopt what works for your and your project.

Successful systems are based on processes that work only because their degree of imprecision is acceptable. This is super helpful in light of the useful consistent lie: the system seems to give adequate results for the current mission (true), therefore, yes, the system "works" (a useful consistent lie).

This is part of why suck less and fail faster seem difficult — it is. To make something out of nothing takes someone capable of thinking differently: the vision, the ability to connect the dots, the capacity to execute, and the patience to get people on board, while also having the impatience to resist being held back — plus a political and economic climate that won't crush those who try. Less than 1/100th of 1/100th of one percent come close (one in a million) in the USA, less elsewhere.

A thousand ways to manifest suck less, fail faster, and technical debt. Helpful bits of wisdom to review on occasion:

• Allowing the disk to fill, and other errors, is to "spin the wheel of catastrophic failure." — Michael Paska, BMC Support
• There is a far more serious risk: a "false negative." That's when there's a problem, but it isn't found. (Contributing to this is confirmation bias, where absence of evidence tends to get treated as evidence of absence.)
• Don't let your work get in the way of your job — don't let your work get in the way of fulfilling your responsibilities.
• Technical debt gets expensive when the service becomes important. Information technology has become a commodity service, and as a commodity service, tolerance for variability goes down as turnaround-time expectations go up.
• Do the right things at the right time and in the right way.
• Documentation is only useful to the degree that it gets used, and is used only to the degree that it's useful.
• Being "correct" but by yourself is less comfortable than being "wrong" with a group.
• Creative ridicule, peer pressure, passive aggression, and other techniques for leadership from behind.
• "Not everything that counts can be counted, and not everything that can be counted counts." — attributed to Einstein
• Correct is a matter of interpretation and perspective — strive for correct enough to be helpful.
• Troubleshooting and problem solving are mutually exclusive.
• There is a limit to what you can usefully worry about.
• "The beginning of wisdom is the definition of terms." — Socrates
• Work left undone due to higher priority is competitive advantage. Work left undone due to misassigned priority is opportunity misplaced.
• Technical debt is bad code.
• Stability, reliability, predictability, and security are inversely proportional to complexity and size. Complexity kills performance; needless complexity kills it needlessly.
• Good technology should make the important easy, and the nice-to-have possible, so consultants can work on the impossible.
• An institution, as soon as it's established, prioritizes self-preservation over its original premise.
• Customer requests for newer, faster, better are less an endorsement of newer, faster, or better, and more an indictment of whatever you're offering now.
• Cost avoidance can be a competitive advantage.

03Embrace the RULES

One of my most liberating realizations is that there's policy and procedure for virtually all "normal situations." In a practical sense, this means: know under whose authority you're acting, know what established approvals are already in place, then confidently assert your adopted authority.

Keep these thoughts in mind: policy, standards, and guidelines make procedures and processes enforceable, repeatable, and auditable.

When presented to the jury of executive opinion, get the rules on your side.

The service catalog lets you preserve the avenue for exceptions while still driving people toward standards.

Evaluate your own IT governance the same way you'd evaluate anyone else's: would you actually want to merge with, or partner with, yourself?

Requirements are binding: "shall." Facts and declarations of purpose: "will." Goals that haven't been tested for: "should." Knowing which word you actually mean saves a lot of downstream argument.

"Security should be appropriate and proportionate to the value of, and degree of reliance on, the IT systems, and to the severity, probability, and extent of potential harm." — NIST SP 800-12.2.3

04Problem Solving, Troubleshooting & Actionable Intelligence

Problem solving, project management, planning, and the like essentially come down to "define failure so as to avoid it." A technique for this:

Identify a problem statement. Make an absurd problem statement (a thesis). Review the ridiculous definitions, solutions, and ideas to clarify what's true about the problem, what outcomes are acceptable, and to expose assumptions. The "do nothing" option should be reviewed first — the more sure you are that doing nothing is a stupid thing to do, the more motivated you'll be to take action.

A real-life example (yes, this one went to HR). Problem statement: Ms. Michelle is hot. Pursue the do-nothing option first — decided that we needed to get to the bottom of it. Absurd thesis: she's on fire. Defined the parts of the problem, the possible solutions, the likelihood that discharging a CO2 extinguisher on her would solve it. Thesis failed — no direct indication of fire, and the available extinguisher wasn't CO2 anyway. Based on that analysis, the thesis got refined: Ms. Michelle is overdressed, in a wool coat, with a winter blanket. Defined the terms — proper dress, proper room temperature, not ill (no fever), compared to everyone else in the room not named Ms. Michelle. Based on that, the thesis refined again: Ms. Michelle is just hot, and there simply wasn't much anyone wished to do about it (no action taken) — which was just as well, since we all agreed that Ms. Michelle's particular form of hot is generally a good condition to have.

Take Action, Always. Every time you view a report, a dashboard, or whatever, you should feel compelled to take action. As above: make a problem statement, analyze it, and take some action. There's a big relief valve in the fact that "purposeful inaction" is an action. With Ms. Michelle, we identified a problem, evaluated it, and took action, even though it turned out to be purposeful inaction. Don't let this become a crutch, but you'll find purposeful inaction tends to be the action more often than you'd expect. (Slides: STLCMG-20180717-Action.pptx)

These tend to be JIT training conversations — sadly, most people won't onboard these ideas unless it's a right-now thing. Almost all of my interns (and some coworkers) have had this exact conversation, and again, it's only effective when it's part of a "right now" thing, not a lecture delivered in a vacuum.

Struggle a little, then ask, and take the help. In troubleshooting, you want to struggle for a little while, but not long. Don't give up, but don't waste time spinning in circles. Spend only as much time as needed to be able to clearly articulate the problem to someone else — then ask for help, and be willing to take it. That struggle is what formulates your own understanding of what you're actually trying to do. What I've found is that the person you ask isn't weighed down by the baggage of the distractions, decisions, and choices you made on your way to understanding — so they get to an answer faster. Partly because they know it's not a simple fix (or you'd have already solved it), and partly because they're being handed the actual problem, where you were the one bogged down in the false symptoms, bunny trails, and distractions.

Cleared while testing is actionable intelligence screaming for attention. Problem-resolution phrases like "cleared while testing," "no fault found," or "resolved without intervention" are road signs pointing straight at actionable intelligence. They indicate a queue, buffer, cache, or other work-holding method has been saturated, causing a visible error. When the system "catches up," the work-holding method releases the backlog and the system returns to a normal state — so it looks fine again by the time anyone checks. Go find that holding method. Understand what it's reacting to. Monitor it as an early-warning metric instead of treating it as a mystery each time. And these messages show up in inverse, exponential proportion to how well the system is actually understood and monitored — the less you understand a system, the more of these you'll get, and ignore, and be saddened by.

Average, on average, is a terrible troubleshooting metric. Minimum, maximum, mean, and the 95th percentile pave the road to actionable intelligence. Average paves the road to hell. On average, based on an average IT conference room full of people: I am 23% girl; on average, she is a boy; on average, your half of the room is below average; on average, even Einstein is average (among prize-winning physicists). All of that is mathematically true and conveys nothing important. It gets worse with scale, not better — the longer the sample period, the less useful "average" becomes. The average summer temperature of Cleveland is about 1% of the average temperature of that same spot across the entire history of the planet. Still technically true. Still useless for anything you'd actually act on. (This is the whole argument behind the talk — see "The Road to Hell Is Paved with Average". There's a companion idea worth knowing here too: most real distributions aren't even symmetric around that average — they're power-law shaped, tall on the left with a long flat tail, where the nth position roughly predicts the nth contribution. That's the same 80/20 logic behind Price's Law, further down in Leadership.)

Which ties into: Analysis should compare data on the same time scale as where the problem actually arises. Looking at yearly data when the problem lives on a weekly cycle is pointless. Looking at minute-level data would be equally pointless in the other direction. Match the lens to the phenomenon, not to whatever granularity happens to be convenient. Don't neglect Min, Max, and the gang.

A single CPU number hides more than it reveals, because at the bottom there's no such number. A CPU is either on or off, 100% or 0%, with nothing in between — the "CPU Utilization = 45%" on your report is already an average of millions of on/off flips per second, and the average of that over a week hides millions more. Max on a minute and max on a week are answering completely different questions. Zoom out far enough and you can average away the exact spike you're trying to find. Put a pretty dashboard on top of an average, and you've just made the wrong answer easier to trust (and the problem more difficult to find). Maybe a job for Min, Max, and the gang.

Dashboards are a fool's shortcut to understanding, not a substitute for it. They're only useful when the context behind them is already understood — and understanding requires context, and context requires understanding, and both take real effort. Making a poorly designed report pretty doesn't make it useful. A chart exists to discover actionable patterns in the data, and your job is to reveal those patterns, not decorate around their absence. Observations are interesting, but not always actionable; insights are the ones that matter, and only because you can actually act on them.

I use the word "molest" deliberately. As in: show me good-looking data and I will molest it — into information. I mean the first dictionary definition, not the fourth or fifth. If your read of that word skipped straight past the first definition, that's your own bias showing up uninvited — worth noticing, and worth not letting sway you. The more you are upset by this statement the more bias you have.

05Communication & Working Together

This one usually comes up as a post-mortem, not a lecture — after a message has already landed wrong, when we're picking apart exactly where it went sideways.

Blue elephant. When the actual noun in a sentence isn't the point — and arguing over it would derail the conversation — substitute an absurd token instead. "We need a blue elephant thing to determine what the list to evaluate is made of." It doesn't matter whether the real answer is a program, a script, a bash script, or something else entirely — that's not the important part, and arguing over it just burns time. Put programmers, admins, DBAs, and engineers in the same conversation, and a blue elephant doesn't offend anyone's sensibilities. Amazingly effective tool and technique, precisely because of how silly it sounds. (Raw examples of the pattern are in the Parking Lot below.)

The 7 Cs, when you actually need them: Clear, Concise, Concrete, Correct, Coherent, Complete, Courteous. These sound like corporate-poster nonsense right up until a specific message keeps landing wrong and you can't figure out why. Run it against all seven and one of them is usually the actual miss — most often Concise (the point got buried on page three) or Courteous (technically correct, delivered like an accusation).

Communication failures are almost always a mismatch, not malice. Assuming there's no nefarious intent on either side, a breakdown in communication comes from some mismatch, and it's almost always one of four seams: what was said (or not) vs. what was heard (or not). What was implied vs. what was inferred. What was meant vs. what was understood. What action was expected vs. what action was delivered. Find which seam actually failed before you assume the other person is the problem. (Candidate for its own presentation someday — this one gets used constantly but isn't a full presentation on its own. Included in other presentations.)

A good meeting looks like this, on purpose, not by accident. An example of a good meeting. It started fast, even though it started a few minutes late (normally a bad thing). There was a focused agenda, the right people were invited, they showed up, and they'd actually done their homework. The tone throughout was respectful but skeptical — not skeptical that someone's position was wrong, but skeptical that it was true in all situations, at all times. That's nuance, and it's what turned the meeting into a real exchange of ideas instead of a series of "you're wrong" statements. Every suggestion and counter-suggestion got offered as a point for debate, not a personal attack, and nobody's comment got dismissed as wrong or stupid. The meeting wrapped 22 minutes early, with a summarized, agreed-to list of solutions sent out immediately. Whether those specific solutions worked is beside the point — the way the meeting itself unfolded is the actual thing worth repeating.

06Risk, Failure & Business Cases

This is the conversation that happens right before a proposal goes out the door, or right after something's already gone sideways and everyone's hunting for someone to blame. Different trigger, same content either way.

Failed with good result is not the same as caused a failure. I call this "failed with good result" — wrong now, but happening to provide a usable result, so that when it finally does get changed, it looks like the change broke something that was working correctly before. It's an inappropriate conclusion, and a genuinely hard one to explain up the chain of command. Concrete version: a device runs on a host table — an appropriate practice at the time. Years later a DNS change happens, as is now the current custom, and the system breaks because it's no longer pointing where it should. Who's to blame? The device was configured to use host tables, which was the right call when it was made; the DNS change simply didn't anticipate host tables still being in use, which is no longer appropriate in the current environment. The device was already sitting in a "failed with good result" state — the DNS change revealed the failure, it didn't cause it. That's an operational risk, and no one is actually to blame for it. If the condition had been suspected, it could have been tested for — but that comes at a real, and sometimes significant, cost.

High risk, high returns — or high losses. We tend to remember the first half of that old adage and conveniently forget the second. A business case is not just there to support a proposal — it exists to establish the cost of avoiding failure. If it doesn't clearly discuss risk, it isn't a business case, it's a pitch.

Taking a risk and failing is acceptable. Failing due to inaction is not. Failure is required for progress — reward productive failure. Progress is measured by success. Growth is measured by failure. Achievement is a mixture of both. Failure is good when it comes quickly and cheaply, and leaves behind experience and understanding as its reward. Failure is bad when it's slow to be recognized, or comes at great expense, and leaves behind a legacy of blame and cowardice instead. Concretely: a two-day proof of concept that flops teaches you something and costs you two days. A production rollout that quietly degrades for six months before anyone admits it's broken costs you the six months, the trust, and usually someone's job. Same failure, wildly different price tag — and the difference is almost entirely about how fast you were willing to call it.

The 10th Man. The group intentionally appoints one person to serve as the loyal dissenter — "loyal" because their underlying motive is still to arrive at the best decision for the organization. As the dissenter, they don't just have permission to disagree and poke holes in the group's assumptions, they have a duty to. It forces everyone to slow down and reconsider the wisdom of the decision, and whether contingency planning or other risk mitigation is appropriate. This is the role I actively take in a lot of conversations — especially when a room is nodding along with no pushback at all. I'll argue against a proposal I actually agree with, just to force the failure modes onto the table and make sure the action is really needed. It reads as disagreeable in the moment. It's not; it's the job. Worth pairing with a harder question: how skilled is your group, actually, at having healthy conflict? Most haven't practiced it. Many don't even agree there's such a thing as "healthy conflict." Many are actively against "arguing a ridiculous point" — it takes practice to not be that guy.

A good plan now is better than a perfect plan later (never). General Patton said it better: "A good plan violently executed now is better than a perfect plan executed next week." Before you even get to execution, there's a cheap way to test whether action is warranted at all: review the ridiculous option first — review "do nothing" — specifically because it clarifies what's acceptable and exposes the assumptions everyone's been carrying quietly. The more obviously stupid doing nothing looks, once it's spelled out, the more motivated you'll be to actually act.

07Change & the Status Quo

This one only lands once someone's already frustrated that nothing's moving. Trying to teach it preemptively is a bit like teaching someone to swim before they're wet — the concepts don't stick until the discomfort is already real.

"If not you, then who. If not now, then when." Two things I say a lot, and they're not two separate ideas dressed up differently — they're a single call and response. Nothing changes until the status quo becomes sufficiently uncomfortable is the observation. Nothing changes until you make the status quo sufficiently uncomfortable is the instruction that follows from it. One names the condition, the other names who's responsible for creating it.

The status quo is emotionally involved in itself, which makes it immune to logic, reason, and facts — we make decisions with emotion and justify them with logic afterward, and emotion is a fearsome opponent of logic, reason, and facts. Related, and worth saying plainly: in a time of constant change, the one thing that hasn't changed is that organizations remain resistant to change. As the Chinese proverb goes, if we don't change the direction we're going, we're going to end up where we're headed. History has really only shown two constants — change itself, and punishment for those who don't adapt to change. Everyone, deep down, already know this, and fear it, in about equal measure.

FUD Dragons. FUD — fear, uncertainty, and doubt — is a strategic attempt to influence perception by spreading negative, dubious, or outright false information. People who use it want you to imagine a dangerous dragon where there isn't one. Usually there's no fact behind it, and the people slinging FUD tend to be bullies and punks who can't survive a fact-based conversation. Occasionally, though, they out-maneuver you anyway and take your lunch money — perception of reality becomes reality, even when the perception was manufactured. Slay FUD dragons quickly, and keep an eye out for the quieter cousins: inattention, and sloth, For they will kill an effort just as dead. Poorly handling the politics, or letting bureaucratic and procedural load pile up, can collapse an initiative just as effectively as an active FUD Dragon can — cost transparency in particular is an active enemy of the status quo, and it will find enemies literally everywhere.

Disruption doesn't stay contained. When you introduce something genuinely disruptive — cost transparency was my example — it sets off a trophic cascade, the same way reintroducing wolves to Yellowstone ended up reshaping the rivers. There will be unintended consequences, some overtly bad, some overtly good, and once the disruption starts, you can't steer which is which. Concretely: an old application costs $50,000 a month (600k year) in hardware support, but only brings in $400,000 a year in revenue. To the good corporate citizens, you're suddenly a hero for surfacing that. To the people whose job depended on the status quo of that application, you're a mortal enemy. Or: a policy requiring 100% duplicate systems in DR for every "critical application" can now be shown to carry a real, specific cost — and good corporate citizens tend to make better decisions once that information actually exists. Be diligent about it; you can derail the whole thing through simple lack of preparation, or by assuming it'll run itself once started. It won't. This kind of work is hard, disruptive, sensitive, and needs constant diligence — the status quo hates you regardless of your intentions.

Illusory superiority feeds every one of the above. It's a cognitive bias that causes people to overestimate their positive qualities and abilities, and underestimate their negative ones, relative to others — shows up in intelligence, task performance, and how people rate their own desirable traits. It'll make you underestimate the difficulty of what you're doing and overestimate your own ability to handle it, and it'll do the same thing to the people opposing you, which means you'll also underestimate their motivation. You are guilty of this. Accept it, and take care to minimize the effect just by staying aware of it's presents — that's the only real defense against it.

08Leadership & Management

This is longer-game material — not a right-now conversation like troubleshooting, more something that gets revisited over months as someone grows into more responsibility.

Levels of Authority — how much rope someone's been given on a task. I started saying these numbers out loud after watching the same failure play out too many times: I'd hand someone a task assuming Level 4 (solve it, then tell me what you did), and they'd quietly execute at Level 1 (look and report) because that's the number they'd assumed I meant — or the reverse, someone would take Level 6 (silent action) on something I actually wanted checked at Level 3 (examine and report) first. Nobody was wrong, exactly. Each of us was just holding a different number in our head, and neither of us had said it out loud. Now I try to state the number before handing off anything that matters — "this is a level 4" takes five seconds and removes an entire category of misunderstanding.

• 0 — Do exactly what's asked, following detailed instructions. Stop and get guidance for any variation.
• 1 — Look into the situation. Get all the facts and report them.
• 2 — Identify the problem. Determine alternative solutions, weigh the pluses and minuses of each. Recommend one for approval.
• 3 — Examine the issues. Report what you intend to do, but don't take action until you check in.
• 4 — Solve the problem. Let me know what you intend to do, then do it unless overruled.
• 5 — Take action on the matter, and report what you did.
• 6 — Take action. No further contact necessary.
• 7 — Delegate, with appropriate controls.

General Colin Powell's thirteen rules. I went to a leadership conference after the Desert Storm(s) and found this a complete but short list to guide yourself by. Be assertive (2, 4, 6, 7, 11, 12). Be calm (1, 5, 8, 13). Be humble (3, 9, 10). Good for a discussion — make your own list. Work on the two you're best at, and the two you're worst at.

1. It ain't as bad as you think. It will look better in the morning.
2. Get mad, then get over it.
3. Avoid having your ego so close to your position that when your position falls, your ego goes with it.
4. It can be done!
5. Be careful what you choose. You may get it.
6. Don't let adverse facts stand in the way of a good decision.
7. You can't make someone else's choices. You shouldn't let someone else make yours.
8. Check small things.
9. Share credit.
10. Remain calm. Be kind.
11. Have a vision. Be demanding.
12. Don't take counsel of your fears or naysayers.
13. Perpetual optimism is a force multiplier. (In the military, you're always looking for ways to increase or multiply your forces — this is a free one.)

Baseball is a decent model for a working team. Winning the World Series doesn't take Herculean efforts from individual players — it takes a magical combination of effective pitching, solid defense, and an ability to score runs. That combination is an elusive brew of ability, luck, and hard work, and the sauce holding it all together is teamwork. Everyone comes to the game prepared: prepared to deliver individual contributions, prepared to accept responsibility for success, prepared to expect success from everyone else too, prepared to contribute to the team for the team's benefit. Prepared to win. Expecting to win. Failure to win is not acceptable — but losing a play, an inning, a game is inevitable, and those get treated as learning opportunities, not personal attacks. Performance gets evaluated as a review of fact, not an insult: conditions identified, strategies devised, plans implemented. There's individual expectation, individual contribution, individual accountability, individual respect — but team success and team failure. For my military friends who love pointing out there's no I in TEAM — you're right, and that's exactly the point: you're a recruit, a sergeant, a rifleman, a ball player, not an "I." But that truth doesn't cancel the other one: individual expectation, individual contribution, individual accountability, individual respect — every one of those words still begins with I. I am prepared. I accept responsibility. I deliver success. I expect success. I will win. Both are true at once, same as this: a batter hustling hard into third, forcing the defense to make two perfect throws and a clean tag, resulting in the third out, is both a good aggressive play and dumb baseball. You can scold one and congratulate the other in the same sentence without contradicting yourself.

09The Parking Lot

Not every good line earns a full explanation, and that's fine — some of these are pure technique-in-miniature, some are just funny, and most interns ask for this section first anyway.

Absurd-token substitutes, odd adjectives, and verbs. Describing something without context is tricky. How do you convey a description of something you haven't even begun to understand? Try it as an array.

Fun with an array — what is going on with that... little | big ole | nasty | icky | homemade bucket of | chunk of | piece o' | slice of love | poo | heaven | hell

Or a short, odd adjective — this (situation, or some noun) is so: boogered up, horked up, hosed, sub optimal (said completely deadpan), completely sub optimal (said with sarcastic surprise).

Once identified, take an action. Doesn't need to be well-defined — use this as the action plan: yuck around with, yuck about, just go break it, liberate the magic smoke, make a resume update (can be positive or negative).

Awards, aspirations, and nicknames. Everyone likes to be acknowledged. I give a "Favorite person for the rest of the day," "Favorite person till lunch," or "Favorite person on this call right now" award liberally, framed so it's clear no one else is getting this award today. Surprisingly warm and effective for conveying gratitude in a routine interaction — I've had stories come back to me of people remembering the conversation weeks later. Small graces and courtesy go a long way, especially in everyday encounters. You do want to avoid the "Dumb ass award," though.

Self-aspiration is also effective. Start a statement with "If I were the smartest boy in my chair, I would..." or any combination from the array below — it's a completely true statement (you are in your chair), and the thought forces a predisposition toward positive energy.

Fun with an array — if I (you) were the... smartest | coolest | dumbest boy | girl | kid in my (your) chair | at my (your) desk | in the world | at my (your) desk at the moment

Nicknames are helpful when the subject isn't the important part of the sentence, so no one gets hung up on "who are we talking about." And I'm terrible at remembering names, so these get used liberally — it's amazing how well a message lands with a ridiculous pronoun standing in for the actual person. Chuckles, chucklehead, dude, girly, hoobie doobie, girlfriend/boyfriend (my favorites), suits (senior management), guys in ties (managers). Don't use "what's his name?" though — that asks a question nobody needs to be distracted by.

Bad ideas are the "best" for clarification and understanding — grade on a spectrum of usefulness, not right/wrong. Elicitation of ideas gets hurt by the phrase "good idea." "Good idea" implies a bad idea exists, and there are no bad ideas, because every idea prompts an analysis conversation. When someone makes a good suggestion, is the next good idea more gooder or less gooder? Rather than binary good / not good, grade use a continuum of usefulness, and evaluate why an idea is what it is. The conversation about why an idea misses is what drives better understanding of the actual problem to be solved, and surfaces assumptions nobody had said out loud. Every idea is valuable because of the discussion it produces about the situation and its assumptions — this works especially well when the more senior people in the room volunteer the more obviously bad ideas, specifically to prompt that conversation, which also gives the more timid people cover to volunteer a "more gooder" idea for discussion.

The full spectrum, worst to best: completely inadequate → wrong → suboptimal → wrong but effective → non-horrible → correct enough for now → correct enough to be useful → in the pool of correct answers (there is a deep end and shallow end) → the most correct answer (somewhat rare in real life)

Shorthand version of the same idea (good to less good): completely non-terrible (this is actually very good) → non-terrible → marginally adequate → doesn't completely suck → completely sucks.

A real-life example — one that sent me to HR (imagine everyone's surprise). The question, or problem statement, was "what's for lunch?" My suggestion (rated "suboptimal" by the team), was to cut off the interns' fingers and have finger steaks with potatoes and corn. The discussion that arrived at "suboptimal" surfaced a mismatch between the average number of fingers on an intern (10, depending on how to count the thumb) and the number of people actually going to lunch (max of 7) — plus the obvious annoyance of removing fingers, the resulting doctor visit, criminal charges, and a non-trivial change to the planned attendance list, which dropped to a max of 2. It also surfaced the assumption that an intern would not, in fact, be good with this arrangement, especially in a short-term temporary employment situation. Other implications, some good, some bad, got discussed, and we ended up at the sandwich shop in the basement, mostly because the cookies were fresh. The lesson, in case you couldn't put your finger on it: the conversation about why the idea was suboptimal for the problem statement was the actual valuable part.

Miscellaneous one-liners. Yeah yeah. but... The problem with that is... (an invitation to explore options, not a roadblock). If I can do that, then I should be able to... — possibly the most useful sentence in computing. Be the packet. Have a nice day, elsewhere / not here. You can't beat that... unless you had a stick. Dumbassery will be severely punished. Whackadoodle. It is not that I am brave, just that I am oblivious to failure. Only in Superman comics are truth and justice sought simultaneously. Request Denied! Resubmit in 30 days for further denial. I'm FINE (Freaked out, Insecure, Neurotic, Emotional). And if you're curious why the DHMO scare site is funny, look up "dihydrogen monoxide." We do not need to review my status as an idiot, as this has been established.

Weekend Safety Brief (internet meme, but it earns its keep): Do not add to the population. Do not subtract from the population. Stay out of the hospital, the newspaper, and jail. If you do end up in jail, establish dominance quickly.

Trivia that occasionally comes up. ¶ † ‡ § © ® ° ± ˜ ² ³ ¼ ½ ¾ ¿ × € — special characters copy and paste. π and τ (2π) which one should be the "real" circle constant — τ (Tau) — see the Two-Digit Pair Analysis Information Technology in the 1500s: stick ciphers, different diameters, shapes, start points, and lengths, right-to-left, base-of-letter indicating the proper symbol — codes, not the real message.

10Quote Wall

Shorter borrowed lines that don't need much unpacking — kept here as reference rather than essayed.

"It is remarkable how much long term advantage people like us have gotten by trying to be consistently not stupid, instead of trying to be very intelligent." — Charlie Munger

"Acknowledging what you don't know is the dawning of wisdom." — Charlie Munger

"Read 500 pages [of books, magazines, reports, etc.] every day. That's how knowledge works. It builds up, like compound interest." — Warren Buffett

"A reliable way to make people believe in falsehoods is frequent repetition, because familiarity is not easily distinguishable from the truth." — Daniel Kahneman

"To better avoid errors, you should talk to people who disagree with you, and people who are not in the same emotional situation you are." — Daniel Kahneman

"In expert tennis, 80% of the points are won, while in amateur tennis, 80% are lost... Beginners should focus on avoiding mistakes, experts on making great moves." — Erik Falkenstein

"Risk is what's left over when you think you've thought of everything." — Carl Richards

"Being slow and steady means you're willing to exchange the opportunity of making a killing for the assurance of never getting killed." — Carl Richards

"Based on my own personal experience, rarely do more than three or four variables really count. Everything else is noise." — Marty Whitman

"The fast way to do anything is not to do it." — Cary Millsap

"People focus on role models; it's more effective to find antimodels — people you don't want to resemble when you grow up." — Nassim Taleb

"The stock market is a giant distraction to the business of investing." — Jack Bogle

"What information consumes is rather obvious: the attention of its recipients. A wealth of information creates a poverty of attention." — Herbert Simon

"Pundits forecast not because they know, but because they are asked." — John Kenneth Galbraith

"The cavalry isn't coming. You are the cavalry. And if the cavalry were to come, you may wish they hadn't." — Josh Spilker

None of this is meant to be quoted verbatim in a meeting like scripture. Half the value is in the argument behind the line, not the line itself — so if one of these lands, ask me about it, and you'll probably get the fifteen-minute version too.