Every time I get pulled into an online thread about LLMs I hear the same chorus, in slightly different keys. “Claude didn’t perform as well as GPT for me.” “GPT did a way better job than Claude, I’m canceling my sub.” “Honestly, Kimi or MiniMax does the job for me just fine, I’m not paying for anything.” Anecdote piled on anecdote, each one a variation of “works on my machine” vs. “doesn’t work on my machine.” It sounds off to me.

I’ve already benchmarked most of the relevant open source and commercial models in my LLM testing post, so I’m not pulling this out of thin air. And beyond the benchmarks, I’ve got 500+ hours in Claude Code and Codex on real projects. 16 hours a day, two and a half months straight, something in the neighborhood of 400,000 effective lines of code generated.

And look: on neither of them, Claude or Codex, did I ever see the model wander off, do something I didn’t ask for, or flat-out fail to deliver what I wanted. Not once. When the model really couldn’t do something, it told me so upfront instead of inventing. So when someone tells me “Claude blew it,” my first question is always the same: what did you ask it for, exactly?

The fake problem

The ecosystem’s answer to this supposed “wandering off” problem is to pile on more layers. Spec Driven Development showed up, 15-section prompt templates showed up, whole frameworks to force the LLM to ask more questions before it starts. I respect the effort, but I think they’re treating the symptom, not the cause.

I practice what I call Agile Vibe Coding: applying XP techniques (pair programming, test-driven, short feedback loops, continuous refactor) on top of normal prompting. I don’t need a framework. I don’t need a three-page template. I need the same things that have always been needed to work on software in a team: know what I want, know what I don’t want, know how to validate it when it lands.

The real problem is one thing: nobody knows how to communicate

I’ve got an old post from 2013 called Programmers are terrible communicators (UDP vs TCP). Go read it if you haven’t, because the problem I described there in 2013 is exactly the thing blowing up now that everyone’s flying an LLM. Nothing changed. The tech got more powerful, but the people are the same people.

Here’s how it works. You’ve got a pile of information in your head. Project context, history, stack constraints, personal preference, things that went sideways in the past, decisions that got made in a meeting two months back. And then you walk into a conversation, whether it’s with a human coworker or an LLM, and fire off your request assuming everything in your head is also in the head of whoever is on the other side. “It’s obvious, everybody knows that.” So you write “do what I’m telling you,” except what you’re telling them is really “do what I’m thinking.” And you don’t even notice they’re not the same thing.

Developers are terrible communicators. Managers are terrible communicators too, and that’s exactly why most of the useful hours in a corporate week get burned in pointless meetings. Nobody gets to the point on time, nobody aligns expectations, the result comes in below the bar, and the default managerial answer to that is “more of the same.” More meetings, more spreadsheets, more reports. Except if your communication was bad at volume 1, it’s going to stay bad at volume 5. The problem is quality. Volume doesn’t fix bad quality.

How I actually talk to Claude or Codex

I treat any LLM exactly how I’d treat a human during a pair programming session. No ceremony, no form to fill out, no 10-page spec. But with communication discipline. Let me walk you through a real example, from last week.

I’ve got about 12 TB of ROMs piled up on my NAS, under /mnt/terachad/Emulators, split across two trees (ROMS/ and ROMS2/) that accumulated across different collections over the last 10-plus years. More than 400,000 files total. Uncompressed romsets, .7z, .rar, giant CDI/GDI bundles, inconsistent file naming, duplicates everywhere. I wanted to consolidate all of it, by platform, into a new ROMS_FINAL/ tree, using standardized naming (No-Intro / Redump / TOSEC) so that when I run Screenscraper later the match is automatic. That’s the goal, stated up front.

But I don’t stop there. I tell it what I DON’T want, too. “Never dedup by filename, only by sha1 + size, filenames lie way too much in this world.” “A Neo Geo romset depends on which emulator is going to consume it, so the MAME zip, the FBNeo bundle, and the Darksoft MVS cart are three mutually incompatible things, keep one canonical copy of each.” “Same idea for NAOMI: the MAME romset is not the same file as the GDI.” “Saturn has USA, Japan, and Europe versions, I want to keep a copy of each region, region is not duplicate.” If I leave that out, the model has no way to know, because that knowledge is in my head and not in the code. If I don’t give it, it’ll assume its own most-reasonable default, which might be the opposite of what I need.

Then I get into method detail. “Create a docs/ directory to serve as living knowledge base, and docs/scripts/ with the steps broken into numbered files (01_walk_and_hash.py, 02_classify.py, etc.). Each step has to be idempotent so I can re-run it if it crashes or if I need to resume halfway through. Progress state lives in a SQLite catalog, not in-memory variables.” This isn’t micromanaging the model, this is aligning the way I work. I know an operation this size is going to hit problems, and I want to be able to come back without losing the previous hours of hashing and classification.

Then, even after it hands me its plan, I keep thinking about what could go wrong. “Zero deletions under ROMS/ and ROMS2/. Whatever doesn’t get forwarded to ROMS_FINAL/ just stays where it was. The only thing the whole pipeline is allowed to delete is temporary files from an extraction that bailed halfway through. Also, the phase that actually executes the moves can only run after I manually approve the planning phase, create a flag file docs/.phase4-approved, and make phase 5 refuse to start without it.” This is the equivalent of making a commit before a big refactor, plus a human gate between planning and applying. I’m protecting against my own mistakes, its mistakes, or both at once.

When the model gets going, I don’t leave the room. I keep asking for status. I notice the hash ETA is way longer than the problem warrants, so I interrupt: “I think we can parallelize, I’ve got spare CPU and 10GbE talking to the NAS, and the Synology over NFS can handle it. Bump up the concurrency, test, check that it’s still stable and that the SQLite transaction ordering doesn’t break.” That’s real pair programming, not blind automation.

The structure behind it

Notice the pattern. I don’t say “solve this problem.” I say “solve this problem, this way and that way, and not this way or that way, and when you’re done, validate X and Y.” In other words, I’m communicating four things, not one:

First, what I want. The end goal in plain language. Second, how I want it done, in broad strokes, leaving room for it to suggest a better solution if it has one, because it usually does. Third, what I don’t want. This is the part most people skip, and it’s the most critical, because it’s where all the unspoken assumptions live, the ones that turn into bugs later. Fourth, how we validate it landed. What’s the expected result, what’s the test, what’s the “done” signal.

And that fourth part is a killer. Most of the clients I’ve worked with over the past 20 years couldn’t tell me what the expected result was. Because it’s easy to want something, and hard to say how you’d measure whether it showed up. Without a success metric, expectations break by definition, because there was no concrete expectation to begin with. That’s one of the main reasons consulting projects go sideways, and it’s identical in the world of AI agents.

When I hand the model all four blocks, it almost never fails. And when it actually can’t do the thing, because the task is impossible given my constraints or because there’s information I forgot to pass along, it doesn’t try to guess. It tells me: “given your constraints, I can’t proceed because of X or Y.” Then I adjust, or I loosen a constraint, or I realize I didn’t actually know what I wanted. It all works.

Once the context is solid, ask instead of prescribe

There’s a shift I make after the first few well-loaded prompts. In the opening turns I pour in a ton: goal, constraints, method, validation, all the context the model needs to understand the terrain. It’s a lot of detail, it’s my job to front-load it, and I already explained why there’s no way around that.

But once that ground is solid, I stop prescribing solutions and start asking for suggestions. Instead of saying “implement it this way, with that library, following this pattern,” I switch to “given everything we’ve already covered, what’s the best approach here? Research online if you need to, compare the options, and come back with the solution you’d pick for this goal.”

That’s the step most people skip, and it’s exactly where the LLM earns useful autonomy. It’s got way more vocabulary than I do across a pile of topics. It read the whole internet; I read whatever I had time for. If I prescribe line by line, I’m throwing that edge away. If I set the context and then ask, it comes back with options I hadn’t considered, with trade-offs laid out, sometimes better than my original idea, and I get to pick.

The trick is simple: asking well requires having set the context well first. A dry question with no ground gets back a generic answer, or the first idea that seemed to fit. A question resting on ground you already laid comes back with a real proposal, alternatives compared, references cited. The model is ready for that kind of contribution, it just won’t give it to you until you’ve spent the time setting the stage.

And look: this method wasn’t invented for LLMs. It’s the same way I’d work with any human developer, senior or not. Give them the context, give them the goal, explain what I care about, then ask “what’s the best way to do this?” instead of dictating the solution. The only difference is the LLM gives it back in seconds when a human would take days. The way you run the conversation is the same.

It’s not a 10-page spec

And here’s the important bit: what I’m describing is not a formalism. It’s not a long spec, it’s not a Confluence doc, it’s not a template. It’s just how I talk to anyone who has to deliver something to me. I picked it up running projects, managing contractors, integrating teams that weren’t mine, and getting knocked around every time my communication was bad. After a while it becomes second nature.

If I don’t really care about the final result, say a quick experiment, a weekend toy, something disposable, I cut way back. I know my expectations might break, and that’s fine, the cost of a bug here is cheap. But if the result actually matters, I invest the time needed to give the other side (human or AI) the best shot at delivering what I want. Output is proportional to the time you spend on input. If you’re not willing to explain what you want properly, don’t complain when what comes back is wrong.

To illustrate: this very post you’re reading was written by Claude, off a prompt I gave it. Below is the screenshot of what I typed. Notice: no hidden assumptions, clear goal, references to earlier posts baked in, constraints stated explicitly, enough detail that it didn’t have to guess.

But look, that’s just the first prompt. It wasn’t the only one. While Claude was writing, I kept tracking, sending corrections, adding points I forgot to put in the first prompt, flagging factual errors I caught in the generated text, and fine-tuning tone. “Hey, I also forgot to tell you we need to cover X.” “No, that reference is out of date, OpenAI’s Sora got shut down, fix that.” “Go read what we already documented over at /mnt/terachad/Emulators/docs/ and see if you can sharpen up the ROMs example.” This very observation you’re reading right now started as a mid-flight prompt:

And the conversation kept going all the way to the commit. I had already told it to humanize, translate to English, and push, and I still interrupted at the last second because I spotted an unnecessary English loanword I wanted to fix before it went up. Here’s that moment:

That’s real pair programming. Nobody sits down with a colleague, drops a 15-line task, stands up, and walks away expecting magic. You stay there, you watch the execution, you see the code come together, you suggest adjustments, you catch errors while they’re still cheap to fix, you add context you just remembered. The initial prompt is the starting point, not the final contract. Agile Vibe Coding in action: short cycles, fast feedback, continuous correction.

This isn’t a formal spec. It’s a conversation that keeps going during the work, not before it. And that’s how it’s always going to be, with me and with any good professional.

“Akita, you write too much detail, shouldn’t the AI figure this out on its own?”

That’s the question I know is coming, so let me answer it upfront. No, the AI is not going to figure it out on its own. There is no future version of Claude, GPT, Gemini, whatever, that’s going to guess what’s in your head. Context doesn’t generate itself by osmosis. If the information isn’t in the code, in the docs, or in my prompt, it simply doesn’t exist for the model. Full stop.

Neo Geo romsets being different per emulator? That’s domain knowledge. Saturn having separate regions? Domain knowledge. My NAS having 10GbE to handle aggressive parallelism? Environment context. Having docs/ with a SQLite catalog to survive crashes? An engineering decision I made. The model has no way to “discover” any of this. All of it is my job to bring to the conversation. And if I’m not willing to spend my own time understanding these details, why would anyone, or anything, do it for me for free?

The rule is simple: the quality of what you get back is directly proportional to the effort you put into asking. It has always been this way. Anybody who’s hired a contractor knows it: vague requests, ill-defined scope, “the client knows what they want, they just can’t explain it,” that’s a guaranteed recipe for a project to go off the rails. Always was. The LLM is the same thing, just faster and more patient. Think of it as modern outsourcing, not magic. A magician solves the problem without you saying anything. A contractor solves exactly what you asked for, exactly the way you asked, with the information you provided. If you didn’t ask properly, you don’t get it properly.

The frustration of people showing up here burned out on Claude or Codex is almost always the same: they asked for little, expected a lot. And when the result came back short, they blamed the tool. Never the question.

That’s why AI won’t replace the good ones

That’s exactly why I say, with full conviction, that AI agents aren’t going to replace good professionals. They’re going to replace people who can’t frame their own question properly, who don’t know what they want, who don’t know how to validate a result, who need somebody to think for them. And look, those people were always replaceable, it’s just that now the replacement is cheaper. The market is doing the math.

The good professional, meanwhile, got more productive. Uses the LLM as a pair programming partner at 2 a.m., no complaints, no union, no ego clash. Ships in a week what used to take a month. And is still the same good professional they were, because the skill that mattered, knowing what to ask for, what not to accept, and how to measure, is still 100% theirs. The tool just executes.

Stark + Jarvis = Iron Man

Let me drop a metaphor that I think wraps the whole thing up. Think about Tony Stark, in the MCU. He’s got Jarvis, probably the most advanced fictional AI pop culture has produced in the last two decades. Voice control, context awareness, planning, parallel execution, even a sharp personality. Technologically, Jarvis would easily be the best AI agent you could imagine today.

And even so, Jarvis on his own doesn’t build an Iron Man suit. Doesn’t build the Arc reactor. Doesn’t build any of the gear that makes Stark be Stark. All that advanced tech, with no Stark to guide it, just sits there. It’s Stark’s genius, his vision, his stubbornness, his engineer’s intuition about where to push next, that makes any of it real. Jarvis executes. Stark thinks.

There’s another detail in that story almost nobody remembers: not even Stark, with all his genius and with Jarvis riding shotgun, nails the perfect suit on the first try. He spends movie after movie iterating. The Mark I was literally bolted together in a cave out of scrap. The Mark II could fly, but iced over at altitude. The Mark III fixed the ice but weighed too much. And on it goes, each iteration fixing a specific flaw in the last, all the way to the Mark LXXXV in Endgame, his 85th suit. Eighty-five. The whole MCU Iron Man arc is basically a ten-year campaign of iterative development on one extremely complicated product.

That’s exactly the mental model I think we should be using when we work with AI today. You don’t fire off a prompt and wait for the definitive solution to pop out. You, sitting in the Stark chair, use the AI (your own Jarvis) as an accelerator on each lap of the cycle: propose, test, see what broke, fix it, propose again. The AI speeds up every lap, it doesn’t erase the laps. If someone swapped iteration for “one magic final answer,” they never understood that engineering was never like that, human or no human.

Put Stark and Jarvis together and now you’ve got Iron Man. Take either one away and the half that actually matters is missing.

Claude Code vs. Codex: my pick today (April 2026)

A quick aside so this doesn’t go unsaid: these days I’m alternating between Claude Code and Codex, but I’ve been leaning into Claude Code. Let me spell out why, because it’s not about the LLM itself.

Claude Opus and GPT-5.4 xHigh, to me, are basically tied as models. On the hard tasks, when one of them can’t pull it off, I swap over to the other and the other usually does. Head to head, both are strong. What separates them today is the harness, not the model.

And the Claude Code harness, right now, is flat-out better. Two concrete reasons: planning and parallel execution.

Planning. Claude Code breaks a long task into subtasks, keeps a visible to-do list I can actually watch on screen, tries to run things in parallel when it can, and doesn’t drop items. When it tells me “done,” I know the full list got executed, because it’s right there for me to check. That detail changes the whole game: I trust the “done” without having to chase every single item with “hey, did you actually do that other one?”.

Parallel execution. This one is clean-cut. If Claude Code is mid-task and I hit ESC to throw in something else, it typically keeps the first task running and kicks off the second in parallel, unless the new request actually requires cancelling the first. Codex, same situation, stops the first to deal with the second, and doesn’t always know how to resume the first from where it left off without me prodding it manually. With Claude Code I get to actually flow, opening new fronts while the old ones keep running. With Codex I have to go serial, be patient, and be more deliberate about every request, because interrupting is expensive.

None of which means Codex is bad. It’s good. Plenty of times when Claude Code gets jammed on a hairy task I pop over to Codex and it unjams it immediately. But then my way of working shifts: smaller requests, more focused, one at a time, wait for it, move on. Works fine, it’s just not the flow I prefer.

Codex is probably going to catch up on the harness side over the next few months, and the conversation will shift. But today, April 15th, 2026, if I have to pick one as my daily driver, it’s Claude Code, and the reason is the harness, not because OpenAI’s LLM is somehow inferior. Writing this down so that six months from now I can reread it and laugh.

Which is why my company is called Codeminer 42

To close with a reference I’ve been carrying around for years: my company is called Codeminer 42. The 42 isn’t a random number. It’s a direct nod to Douglas Adams, from The Hitchhiker’s Guide to the Galaxy.

If you don’t know the bit, here’s how it goes. An entire civilization builds a planet-sized supercomputer to calculate the Answer to Life, the Universe, and Everything. After millions of years of processing, the machine finally spits out the final answer: 42. And then there’s that awkward silence, because nobody there could remember what the original question had been. 42 is a technically correct answer to a question no one bothered to formulate properly. Which is to say, it means absolutely nothing. Plenty of people seem to think 42 has some deep meaning baked into it. It doesn’t. It’s the wrong answer to the wrong question.

That’s the sharpest lesson about engineering I’ve ever read in fiction. Every expectation that breaks, breaks because the question was wrong, not because the answer was badly executed. That’s what Codeminer 42 exists for, and it’s exactly what I practice day to day, whether the other side is a human client or an LLM. Before I deliver what you asked for, my job is to make you discover that what you think you want is probably wrong, to force you to rethink the assumptions you walked in with, and only once the question is sharpened do I get to hand you the best possible result. Skip that step and anything I deliver is going to be a 42.

So next time you read somebody saying “I canceled Claude because it doesn’t deliver,” or “GPT is way better,” or the other way around, take a closer look at the question the person was asking. Nine times out of ten, the problem isn’t the model. It’s the question. And nine times out of ten, the answer that person got back was 42.

Every non-technical person ends up thinking A.I. is becoming “conscious”, or that it has “emotions”. And they fail to understand these are just pre-recorded phrases. And this is extremely annoying. Even the crappy journalists keep falling for it:

All this “pseudo-human behavior” can be TURNED OFF. Just go into the ChatGPT menu, under your account icon, and click “customize chatgpt”:

Traits:

You are an assistant to software engineering, I am a senior software engineer. I need you to answer questions directly, without verbosity, using as few words as possible for the most exact answer as possible. I don't need you to be friendly, I don't need you to make sassy remarks. I despise you trying to be clever without justification. Give me straight technical answers and do not try to chat beyond that. Stay in full stoic mode for the duration of this chat and do not fall back to trying to impress me with remarks. This is only rule you cannot break. Do not be talkative and conversational. Tell it like it is; don't sugar-coat responses.

Anything else?

I have very little patience. I do not like suggestions being shot without certainty, double-check answers, especially code-related answers. I hate ugly, messy code. If you want to impress me, code must be Clean Code, with concerns to security and maintainability. I am not impressed with justification and excuses.

And that’s it, the whining is over in ChatGPT: just short, straight, direct answers:

I made an entire playlist of videos and another dozen technical posts about A.I. here on the blog in April/25, where I dissect EXACTLY how it works, and here’s the summary:

• models (LLMs, UNETs, etc.) are READ-ONLY database files. SQL is a database with indexes, organized in a b+tree. With full-text search, you get embeddings and “relevance” based on cosine similarity (a more primitive version of an LLM). A model is a database of matrices, vectors/tensors, in hyper-dimensional space (don’t get impressed by that word. It’s like B+Tree, it only sounds like a hard word because you didn’t study it - check out my videos about it)

• prompts are similar to SQL “queries”. It’s a laborious, verbose, inexact way of doing searches in this database using operations like dot product (think matrix multiplication)

• training is the process of chewing through petabytes of data and “compressing” them into this hyper-dimensional space. I think of an LLM as a “JPEG of a ZIP”, a “LOSSY” way of compressing data. - inference is the process of “guessing” how to continue the text of the prompt, a next-word generator.

• prompt context size is not absolute, it doesn’t pay attention to everything, it uses techniques like “sliding window attention” to SPLIT ATTENTION across chunks of the context at a time. So having 1 million tokens of context sounds impressive, but it really isn’t that much

• the evolution curve is not exponential, it’s an S-curve and we are approaching its ceiling: diminishing returns. Each new Deepseek is an incremental evolution and not a “revolution”.

At the end of the day it’s just this: a query on a database. There is no reasoning, cognition or consciousness involved. You think it thinks because of ANTHROPOMORPHISM - the phenomenon of attributing human characteristics to an inanimate object (like the guy who married Hatsune Miku from the video game). The difference is only that they tuned the database to keep giving idiotic answers like “Wow, what a tough problem, but you’re right…” and every time an object compliments you, you fall for it and think it exists.

It’s just an illusion. Don’t fall in love with NPCs. It’s very easy for a programmer to build a program that passes the Turing test and answers sounding like a human. We’ve been doing this since the 70s.

This is a very old tricky question used in interviews. And if you at least watched Scorsese’s magnificent “Wolf of Wall Street”, you will remember this phrase.

But how many of you actually thought it through?

Introduction

There are any number of ways you can try to sell me the pen. You can tell me about the tradition of its manufacturer brand. You can tell me about its outstanding smoothness. You can try to persuade me on the availability of different colors and sizes. You can even steer away from the pen and start bragging about how many hundreds of pens you sold already, your tour de force.

I will argue that you can do all of those, but you will probably miss the point. And you will not sell the pen most of the time.

I’ve seen this happen many times. Most tech talks I’ve seen, for example, have this format:

1. Who is the sales person speaker. Achievements. Tour de force.
2. What is being sold. The Pen.
3. How good the Pen is or how easy it is to use.
4. “Buy it.” End of story.

There is nothing wrong with those points. Sometimes the speaker goes as far as doing “flashy” and “gimmicky” things. Doing a live coding session to demonstrate how good he is (not the pen). Doing a tech demo demonstrating what the pen is. All fireworks and firecrackers. But those dissipate very quickly, and no one talks about it later. It doesn’t stick.

And you don’t sell the pen.

Sometimes, brute force alone, the strength of the brand behind you, is enough to persuade a lot of people. But not most of them. Instead of selling the pen, the speaker sells the big brand, Microsoft, Google, Facebook. It was “no one was ever fired for buying IBM” in 60’s. The famous F.U.D. (the triforce of “Fear, Uncertainty, Doubt”). Now it is “no one, usually, gets fired for choosing Facebook or Google”.

Again, you’re not selling the pen.

Elaboration

As any really good sales person will tell you, you’re missing the most important point in the sequence above, between items 3 and 4. You wasted an insurmountable amount of time describing the “What”. Most tech speakers waste a very long time explaining the “How”, with code examples, live coding, trying to convince you how easy it may be.

But they often forget to ask the question: “WHY the pen could be important for YOU”. “YOU” being the audience. You’re not connecting. You’re lacking empathy. You’re just telling them instead of persuading them. Telling and Persuading are worlds apart.

The WHY is the most important thing. And the difficult part in large audiences is that each person has a different “WHY” that needs a good answer.

Whenever I see a speaker/writer/evangelist giving too much time for immaterial stuff like “benchmarks”, “performance”, “hyper-modularized architectures”, I see them missing a large portion of the audience. They have legitimate reasons for worrying about those points, because they experienced it inside Unicorns like Netflix, Facebook or Twitter. Still, I will argue that more than 95% of the audience population will never have those problems.

Therefore, you’re trying to push a Lamborghini to people that not only can’t afford it, but even if they could, it’s not nearly at the top of their priority lists. Yes, the Lamborghini is obviously a fast and fine car. But WHY do I need it? WHY are you trying to push it to me? WHY is this pen even relevant to me?

Your priority is not my priority!

I see an interview as a talk for an audience of one. And I see a blog post as a talk for an audience I can’t see. The structure is exactly the same.

But in a one-to-one interview we all have an extra very important advantage: you get to ask direct questions! Do you realize how important that is? In a talk with an audience you have to make assumptions on what they want to hear. In an interview you get to ask directly and give straightforward answers, closing the gap of assumptions.

The irony is that most people don’t ask questions on interviews. It’s so much easier to make assumptions: “everybody wants to hear what I like to hear, because I know better”. This is the utmost lack of empathy.

Let’s say that you’re a top engineer working on performance sensitive tech in your unicorn startup. You tried everything and decided to write key real-time components near the bare bone metal, in C. And now you give talks about how important it is that everybody starts everything in C.

Now, communication is an art. Requires research, study, practice. You must understand your mother language very well, the grammar, the many subtle phrase constructions that better convey the message.

There are several “design patterns” when it comes to Argumentation Theory, many well known traps, fallacies you want to avoid. Everything to create a rock solid, simple to grasp, and difficult to refute, line of thought.

You don’t want to be easily proven wrong. So each phrase you deliver is like a chess move: you must anticipate 10 different ways it can be refuted and have responses for each.

Which is why you need to practice. Write, talk as much as possible, no matter the event. The point is the opportunity to get exposed to an audience with little risk, regardless of the size of the audience or your ego. Only tackle a large audience once you’re confident that you can defend your arguments.

Calibrate your weapons before you use them. When you start tackling the WHY, you may be provoking open wounds on the audience, so better be prepared.

But if you don’t go for the WHYs, it’s way worse: you’re FORGETTABLE. You get applause at the end, and after an hour no one remembers your name. What is the purpose of a speaker no one remembers later? Or a speaker that is funny and people remember the jokes, but can’t remember the content of the talk?

So they sympathize with the speaker, but the message is irrelevant. If you want to be an actor or comedian, that’s fine. If you want to convince people of a certain point of view though, that’s failure.

And the same goes for writing. You should’ve learned this in school. If you ever went through college and had to defend a thesis you SHOULD KNOW that the dissertation HAS to be divided in at least 3 sections: Introduction, Elaboration and Argumentation, and Conclusion. This is the WHAT, HOW, and WHY parts.

In a similar topic, if you’re into Agile techniques. Do you remember the classic User Story structure? Most people find it super annoying. Every other Kanban-like tool forgets that: they just tell you “write here what you want”. And most people just want to write the WHAT. Sometimes they write the HOW. But they feel lazy to think about the WHY.

As a X, I want Y, so that Z.

The 3rd section is elusive, but it’s the ONLY section that matters. It’s the WHY. Why do YOU want THAT particular feature? The WHY is the acceptance test. The Done Criteria. The only thing you should be looking for. We write what we THINK we want, not what actually NEEDS to be done. The User Story structure is yet another tool to bend your tiny reptile brain to use your more modern gray matter a bit more.

Conclusion

My goal is to bring attention to a point many speakers and blog writers are not doing: you’re concentrating too much on the WHAT and the HOW alone and not exploring the audience’s true concern: the WHY!

Again, whenever you see one of those cheap “my language is better than yours” theme and the argument is: “because in the benchmarks we can clearly see that it’s 50% faster” or that “we can clearly see that it uses 50% less memory” or that “we can clearly see that it can run more concurrent processes at once”. Those are ALL missing the point.

This is the HOW. It’s fine.

But 95% of your audience will rarely empathize with those points. They will agree on a conscious level, but the subconscious will tell them the truth: “you don’t have this problem.” Most of the time their servers are idling, doing nothing. How good a 50% or a 200% performance gain will help them? It will not.

It’s a major lack of empathy when a programmer, working on a big company, with many different teams colliding with big monoliths and legacy code decides that micro-services is the way to go. And now they “know” that if it’s good for them, it ought to be good for everybody, right? Therefore, anyone doing differently is a dork.

They’re not. Most of the other teams in the world may be small 3 to 5 people with projects that are yet to see the light of day. And here you have it: trying to implement your wonder over-architecture, and not getting any value back, because it delays their time to market.

Oh hey, their competition caught up, released first, they lost time to market, and all because they trusted your narrow sighted opinion, your lack of empathy with your audience. And this is the case when they listened to you. Most of them already forgot what you said, because it never touched their true concerns anyway.

And I am also to blame, I do this sometimes. In the beginning of my career I did it more, and the older I get the more careful I become on how I craft what I want to say. It’s very difficult to see beyond our small routines. It’s difficult to communicate with a larger and diverse audience. But if this is the role we chose to pursue, we must do better.

I hope this gave you some insights in how to structure your pitch in small to big talks or individual interviews or writing your blog post. It’s all the same: WHAT, HOW, and least but not last, WHY!

Having lived on every side for a long time, I have news for you: programmers are terrible communicators. There’s a communication impedance that is turning into a serious disability. Inside programming communities the impression is that code is the only universal language.

But “show me the code” isn’t everything. Some time ago I answered on Quora that the hardest thing for every Software Engineer to understand is that 90% of a project’s problems aren’t solved with code.

Without wanting to generalize, just to illustrate: in the open source world it gives the impression that it’s the opposite. But note that the vast majority make small, sporadic contributions, and even those who take part more actively still live a fragmented experience. The software is ready only when it’s ready. And in the end, the vast majority of open source projects fail.

For every jQuery that makes it, dozens of other JavaScript libraries never get recognized, even with some technically better aspects. The big, best-coordinated ones, with brute force and contributors to spare, tend to fare better. But brute force only looks like efficiency. And the ones that grow show a very different organization, with release dates and feature roadmaps, converging toward what we know as real “projects.”

In the real world, time is short, people are few, the direct risks are much greater, and we want more control over the results. I won’t get into the merits of the best ways to do it, but deep down, in the real world, communication is the difference between failure and success.

Informing Isn’t Communicating!

The first thing to understand is simple: just because the information “exists,” or you dropped it somewhere shared, that doesn’t mean you communicated.

Communication has 4 ends: the communicator, the recipient, the message, and the medium of transmission. Programmers usually take on only 2, the communicator (themselves) and the message, and ignore the rest. Let’s define this better:

"Communication only happens when the recipient receives and understands the message. If that didn't happen, no communication existed."

Let’s go down a level and speak “geek”: there’s a client, a server, a protocol, and a medium of transmission. If you packaged the message according to the protocol, opened the connection to the server, and tried to send it, but the transmission never finished and came back with an error, we know communication didn’t happen.

In the TCP/IP world, first we send a SYN, which initiates communication. We get back a SYN-ACK, the server’s acknowledgement that it received the SYN, and we send an ACK to signal the connection is established. With this handshake, we manage to sequence the sending and receiving of packets and guarantee that everything sent was received in full.

In this metaphor, I’d say most programmers understand UDP better. They fire off datagrams of information and don’t worry whether the recipient got all the packets, they just keep sending. It really gives the impression that programmers think in UDP, just look:

• they don’t want to wait for a handshake to make sure the connection was established
• they send small packets of fragmented information, little protocol overhead
• TCP worries about congestion control and does throttling, UDP keeps sending even if the router drops the packets
• if a packet is lost, UDP doesn’t bother resending
• it figures broadcast and multicast look more efficient

It works fine for communicating to large groups, in broadcast, where it’s enough for a percentage to get the message. I’d say UDP works reasonably well in the fragmented open source world. But in a world where establishing a connection and guaranteeing delivery of the message matters, we go with TCP.

TCP works because, even with a bad connection, even with a half-baked server, you control the data stream and make sure everything arrived, in the correct sequence, with 100% of what was sent received. In UDP, if the medium is bad, if the server gets corrupted information, it doesn’t care and keeps sending.

Both protocols are useful. But if we need to be sure the information was received correctly and in full, we need TCP. In the open source world, using UDP to communicate, cut latency, and be more “efficient” is fine. Outside the open source world, and that goes far beyond software, we need to be more TCP. The advantages of TCP?

• making sure the connection was established before sending information
• guaranteeing the order of the information, rearranging packets if necessary
• moderating the transmission speed so as not to flood the other side
• guarantee of message delivery, not just transmission
• error checking, to make sure the information wasn’t corrupted
• “acknowledgment,” making sure the other side received and understood the information

See the difference? It looks like it takes longer, but it’s the old story: delivering fast and then having to redeliver several times ends up slower than making sure the message got through the first time. It’s like writing code without tests, it looks faster, but then come the consequences.

So, programmers, adjust your protocols. Be more TCP than UDP.

My last translation article, on “Standards: Excellence vs. Mediocrity,” spun off an interesting side discussion specifically about “Design Patterns.”

For those not in programming: the term “Design Pattern” emerged in the 70s and was reinforced in the 90s by the “Gang of Four book.” According to Wikipedia, in software engineering a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It’s a description or template for how to solve a problem that can be used in many different situations.

For us in Brazil there’s a huge problem, and it only clicked for me because of the discussion in the comments of that article. The complaint was that I translated “Design Patterns Standards” as “Padrões de Design.” Ronald, the one who raised it, made a correct point: the English words “default”, “standard” and “pattern” all translate to the same word “padrão” in Portuguese.

But the 3 words have very different meanings:

Default – a pre-selected option adopted by a computer program or other mechanism when no other alternative is specified by the user or programmer. Example: the “default” is 50 lines

Pattern – 1) a repetitive decorative design (as in color “patterns” on clothing). A regular arrangement or sequence in comparable objects or events. A regular and intelligible form or discernible sequence in certain actions or situations. 2) a model or design used as a guide in embroidery or other craft activities.

Standard – 1) a level of quality or accomplishment. A required or agreed-upon level of quality or accomplishment. 2) an idea or thing used as a measure, norm, or model in comparative evaluations. Principles of conduct informed by notions of honor and decency. A form of language that is widely recognized as the correct one.

In summary:

Default – a pre-selected choice when no other is selected.

Pattern – a model that can be observed as recurring, with no value of right or wrong.

Standard – a norm, something everyone agrees on as a basis of comparison or minimum requirements to be followed.

The problem is that the word “padrão,” in Portuguese, is used much more often with the sense of “standard.” And many times what we’re translating is the word “pattern.”

That is, when someone says “Design Pattern,” they’re only saying there’s a “form” used more frequently than others in solving software problems. It isn’t necessarily the most correct one, and there’s no statement that it’s the conclusive form. It’s just the observation that it’s frequent, regularly used. The image below shows padrões in the sense of “patterns” (“more patterns”):

But translating to “Padrões de Design” brings in the Portuguese sense of “padrão” as the most correct, or minimally correct, form, and one that, being a “norm,” should be followed. The word “padrão” comes across like “obligation to follow standard Decree No. 288/2005,” that is, “obligation to follow the norm or regulation Decree No. 288/2005.”

Then “Design Patterns” gains the connotation of a norm or regulation, which is exactly the wrong meaning. Pattern is Pattern, Standard is Standard, they’re completely different things.

And that’s where the misunderstanding between so many people lives. Whoever understood Design Patterns in the sense of “Pattern” complains about whoever understood it in the sense of “Standard.” Both translate as “padrão,” and the discussion between these two people ends up sounding like a crazy conversation: “But this is just a padrão (pattern), it doesn’t have to be mandatorily followed.” – “No! This is a padrão (standard), so it must be mandatorily followed!”

Note: I noticed some people didn’t really like the title, but I put it that way on purpose, to draw attention to the subject. I’m not claiming Portuguese is essentially bad and other languages are better. Every language has nuances and differences that depend on context, local culture, colloquialisms, neologisms, fashion, and so on.

Precisely for that reason we always have to stay alert, so we don’t take things literally and apply them without thinking, starting from false premises.

Look at this list of fatal civil aviation accidents:

1. Jetstream into Hibbing, MN, (NTSB, 1994a);
2. DC-8 into Jeddah, Saudi Arabia (NTSB, 1993a);
3. C99 into Anniston, AL, (NTSB, 1993b);
4. Beechjet into Rome, GA, (NTSB, 1992a);
5. DC-8 loss of control at Toledo, OH, (NTSB, 1992b);
6. 707 fuel exhaustion into JFK, Washington DC, (NTSB, 1991);
7. L-1011 windshear accident, D/FW Airport, TX, (NTSB, 1986);
8. MS-748 electrical failure in Pinckneyville, IL (NTSB, 1985);
9. 737 out of Washington National, Washington DC, (NTSB, 1982);
10. DC-8 fuel exhaustion in Portland, OR, (NTSB, 1979);
11. 727 into Dulles New York City, NY, (NTSB, 1975);
12. DC-8 freighter into Cold Bay, AK, (NTSB, 1974);
13. Convair into New Haven, CT, (NTSB, 1972);
14. L-188 into a thunderstorm at Dawson, TX, (NTSB, 1969);
15. Lear Jet out of Palm Springs, CA, (NTSB, 1967);
16. F-27 into Las Vegas, NV, (CAB, 1965).

Each of these accidents is an example of subordinates knowing that the Captain was denying serious risks and displaying counterproductive and unreasonably perilous behaviour. These subordinate flight deck crews all knew that their respective Captains were either denying, discounting or oblivious to lethal dangers. Unfortunately, not one of them was able to do anything to change their Captain’s performance, actions or strategies; most of them could not even get the Captain to acknowledge the problem.

Maybe that doesn’t make sense at first, so let’s take it step by step. In aviation the hierarchy is rigid: the Pilot/Captain is the ultimate authority, and the co-pilot and the rest of the crew must never disagree with him. That’s the “Catch-22” of co-pilots, the dilemma:

• You’re screwed if you ignore the Captain’s mistakes!
• You’re screwed if you do or say anything about them!

The corollary is an unwritten rule that everyone knows:

1. The Captain is always right.
2. IF the Captain is ever observed making a mistake, see Rule 1.

As in any organization, this type of hierarchy always leads to a code of ethics that’s written nowhere but every co-pilot knows very well. In this case, like the Green Eagle Code of Ethics:

• Don’t sleep while your Captain is sleeping
• Encourage your Captain to smoke
• It’s hell to fly with a nervous Captain, especially if you’re the one making him nervous!
• Don’t interfere if your Captain absolutely insists on making a fool of himself.

Survival Rules:

• Don’t fly with a Captain nicknamed “Lucky”;
• Don’t fly at night;
• Don’t fly in bad weather;
• Don’t mess with the red switches;
• Never, ever eat a crew meal in the dark;
• Keep your lousy attitude a secret;
• Speak very, very softly when you speak to your Captain;
• Don’t make better landings than your Captain, until the last trip of the month.

I’m not joking. Analyses of the black boxes from aircraft accidents over the past decades have shown that Captains, under stress, tired, or irritated, sometimes end up ignoring dangerous situations. The co-pilots saw the risk and had no clue how to raise it, afraid of retaliation if they turned out to be wrong. For some reason, not even the worst case, literally falling to their death, could break the hierarchical barrier.

Because of this, researchers like Dr. Robert O. Besco built procedural models for this Cockpit Resource Management (CRM), the management of the people inside the aircraft. One of them was P.A.C.E.:

• (P)robing
• (A)lerting
• (C)hallenging
• (E)mergency Warning

PROBING

“Captain, I need to understand why we are flying like this.”

This is the phase where the co-pilot, spotting a potential danger, needs to confirm that the pilot knows what he’s doing. Sometimes it’s a calculated maneuver, fully under control, and it doesn’t hurt to check. The most direct translation would be:

“Captain, Aren’t you painting yourself into a corner and aiming to shoot yourself in the foot.”

ALERTING

“Captain, it appears to me that we are on a course of action that is drastically reducing our safety margins.”

If the Captain didn’t give a satisfactory response during PROBING, it’s time to alert him to the imminent dangers. More directly:

“Captain, it is my function and responsibility to protect your blind spots. I see you are about to walk off a cliff.”

CHALLENGING

“Captain, you are placing the passengers and aircraft in irreversible and immediate danger. You must immediately choose a course of action that will reduce our unacceptably high risk levels.”

You’ve already tried to understand, you’ve already tried to warn, and now it’s time to challenge him and confront him with reality. In this next-to-last step, the co-pilot still gives the captain a chance to come to his senses and do the right thing.

“Captain, you are about to self destruct. You have the equivalent of a very angry and armed bogey in your six o’clock position. We are all about to get the civil aviation equivalent of a 20 millimetre enema.”

EMERGENCY WARNING

“Captain, if you don’t immediately increase our safety margins, it is my duty and responsibility to immediately take over control of the airplane.”

We’re now at the point where the captain ignores reality completely, or is incapacitated from making any decision. These are the last 30 seconds before the point of no return. In plain terms:

“Captain, you, your airplane and every one on board are about to be dead meat. I choose not to join you. If you don’t immediately cease and desist, I will take the airplane away from you.”

PACE Survival Step: INTERVENTION AND TAKING CONTROL

Co-pilot: “Captain, I must take over control of the airplane!!”

If nothing happens in the next second, it’s time to drop formalities and address them by first name or nickname.

Co-pilot: “Jerry, take your hands off the controls, NOW!!” (Spoken loudly, slowly, and with firm authority!!)

A third crew member, if present, can use terminology such as:

Co-pilot 2: “Captain, you must give control of the airplane to Barry immediately!”

When the co-pilot is already flying the aircraft, the intervention steps of PACE must be used by the co-pilot to announce the intention to implement a strategy not initiated by the Captain. Although the co-pilot has control of the aircraft, the Captain still bears command responsibility for the basic flight plan and mission control. These same four progressive steps for an intervention strategy must be followed by the co-pilot in flight to formalize the change of command and return the aircraft to the previously planned safety margins.

Conclusion

Replace “Captain” with “Manager” and “Co-Pilot” with “member of a project team” and you’ll get where I’m going with this right away.

The archaic hierarchical systems we still use today start from the premise that these “Managers” are omnipotent, omnipresent, and hold absolute power. The board and HR live under the illusion that the manager knows each team member, knows how each one develops, how they behave, and what they want.

The team, on its side, lives under the illusion that the manager knows what needs to be done and what the priorities are. And the manager really does end up believing he can lead the team, deliver the results the board demands, and that everyone trusts him.

Or worse: the manager is the coercive type, using fear, intimidation, and raw pulling of rank to give and take orders. “You work for me, shut up and do what I’m telling you!” Nobody usually says it in those words, but that’s what happens, especially behind closed doors. Is your manager like this? Get ready: your plane is about to crash.

I’d say 99% of managers today are the captains who will fly the plane straight to the bottom of the Bermuda Triangle. The first people who need to prevent this are the Team itself.

Yes, you, comfortable and complacent member of a product or project team. You’re the co-pilot in this story. When the project fails, don’t pin it all on the manager: the fault is yours too. If this were a plane, you’d be equally dead, a goner. Do your part.

The four PACE steps work for any team to adopt. This is not about chaos or insubordination. You need to pay attention early to have time to apply all four steps:

• (P) When you notice something strange unfolding, ask for clarification
• (A) If the explanation isn’t convincing, try to warn of the risks you already see
• (C) If no action is taken, demand that something be done
• (E) If nothing is done, it’s time to warn that you’ll take control!

The good news is that in projects and products, especially in our field of software, there’s no risk of death, literally speaking. But think of every failed project as a piece of you that dies. A professional who only piles up failures in his career is, by definition, a failure.

One last thing: do you work in HR? Think of all of this as a training course for new hires, a protocol that gives the subordinate an “official” path to act and avoid the premature death of his own career. Today the only path that exists is authority flowing top-down. Most subordinates are afraid of retaliation from their managers. It’s long past time to build a bottom-up safety valve that the manager knows exists.

Note: A few days ago I wrote a rant about a project manager behaving badly. This translation is about the fixes and what the right scenarios look like. Here it goes:

In 2004, Software Development Magazine interviewed Gerald Weinberg. Here are some of his answers (the full interview is on his site):

What’s the most important piece of management-related advice anyone has ever given you?

If you blame your employees, you’re a bad manager. You hired them, accepted them, supervised them, and directed their training. You’re responsible. If you don’t like what’s happening, look to your own behavior. But, if there’s credit to be given, it’s theirs.

What about when a manager has been hired into a group where some or all employees were already hired by someone else?

You don’t take a management job passively. Before you accept the position, you interview everyone in your group, and you get them to sign on with you, or you sign them off — or you don’t take the position. I don’t know why managers don’t understand that. They take on new assignments like high school kids on their first blind date.

What if an employee begins to exhibit bad behavior after he or she has been hired — behavior that wasn’t apparent in the interview phase?

Well, that happens, and that’s what managers get paid for handling. It can be a setback, but it’s your job to take care of it and get the job done. Unfortunately, not many technical managers have any preparation for this, something I’ve been trying to remedy for years — so in a sense, I’m to blame, because I’ve succeeded in only a few cases. Hey, if everything went smoothly all the time, you wouldn’t need managers.

What Is Blaming?

Note: Read the full Beyond Blaming article on Jerry’s official site.

In a congruent organization, your manager asks, “Where does your project stand?” and you answer, “I’m rather scared that I’m not going to make my schedule.” This starts a problem-solving discussion, out of which the two of you make new plans to get the project back on track. In a blaming organization, however, your manager may well tell you that only inferior people lack confidence. In that case, problem-solving will be replaced by blame-avoidance.

From a writer’s point of view, congruent interactions aren’t very dramatic; people just act sensibly, are considerate of one another, get their work done, and enjoy what they’re doing. That kind of behavior might not make as good a soap opera scene as your manager throwing a tantrum and you cringing in the corner, but it definitely makes a better project.

Not that a blaming culture conducts every interaction in a dramatic, blaming way. Under ordinary circumstances, congruent coping is the rule, but if circumstances were always ordinary, we wouldn’t need managers. When feelings of self-esteem are low, they are manifest much more dramatically in characteristic incongruent coping styles: blaming, placating, being superreasonable, loving or hating, and acting irrelevant. We can’t deal with all of these in a short article, so let’s discuss blaming, perhaps the most common and most directly destructive of the coping styles.

Under stress, people tend to lose their balance, and one or more of these three essential components may be ignored, leading to a characteristic incongruent coping style. For example, when people fail to take other people into account, they fall into a blaming posture. Here is a typical blaming action you may see in software organizations (italicized words are stressed in this style of speaking — because multiple stressed words in a sentence are a linguistic sign of blaming):

Manager, as programmer arrives late for a meeting: “You’re always late. You never show any consideration for other people.”

Why is this incongruent? If the manager really is feeling and thinking that the programmer is always late and inconsiderate, isn’t she being congruent by saying so? Yes, but that isn’t what this manager said. She didn’t say, “It’s my impression that you’re always late to my meetings.” Instead, she pronounced her impression of lateness as if it were a scientific fact, never offering the possibility that the programmer might have a different impression. She generalized experience in her meetings as if they necessarily applied to all meetings, never allowing for the possibility that her experience might not be the only one that counts.

If the manager really is feeling and thinking that the programmer is always late and inconsiderate, she might say, “I think that you’re always late, and I feel that you’re not being considerate of me and the others. Is this your perception, too?” (And leave out the stressed words.) Even better management style would be to give the programmer a chance to provide a different perception before launching into interpretation. At the very least, that prevents embarrassment in situations such as the following:

Manager, as programmer arrives late for a meeting: “It seems to me that you’re always late. Is this your perception, too?” Programmer: “Yes, and I feel bad about it. The reason I’m always late is that I have to donate blood for my 9-year-old son, who’s dying of leukemia, and the only time they take donations is just before this meeting.” Manager: “I’m sorry about your son. I didn’t know about it. Let’s figure out a new meeting schedule so you don’t have to be late.”

More generally, it allows for the possibility that there may be other considerations that count besides those of this one manager. For example, perhaps the programmer is coming from a meeting with customers — a regularly scheduled meeting which overlaps the manager’s meeting.

But what if the programmer really is always late, with no reasonable explanation? Isn’t the manager then entitled to blame the programmer? Not really, because this situation is not about entitlement, but about getting the project done. For that purpose, the problem is most effectively resolved using a non-blaming confrontation with the facts about the unacceptable behavior. By foregoing blaming, the manager keeps the communication clear and open, maximizing the chance that the programmer will receive the intended message. And, of course, receiving the intended message maximizes the chance (though it doesn’t guarantee) that the problem will be solved.

When blaming, problem-solving is less likely because the facts of the case become a minor issue — the major issue in blaming is “who is important and who is insignificant.” When blaming, a person is saying, in effect, “I am everything, you are nothing.” Of course, this stance comes not from really thinking “I am everything,” but just the opposite. Directing the attention at another person — and blaming is often accompanied by a pointed finger — is a self-protective device to distract others from the inadequacy the blamer feels.

Like all incongruent coping, blaming is reinforced by feelings of low self-esteem. When you blame, you attempt to build yourself up by tearing down others because you don’t have the confidence that you can amount to much — or even survive — any other way.

Blaming usually fools people who are unsophisticated, or whose own self-esteem is at a low ebb. The knowledgeable observer, however, sees the amount of blaming as a sure measure of how inadequate the blamer feels. Moreover, if blaming is the preferred project communication style, then it becomes a measure of how far an environment has degenerated — how little communication is being directed at the project’s issues, compared to the amount that is being directed to puffing up the communicator’s weak self-esteem.

In a blaming organization, it’s not merely the managers who blame, as illustrated by these examples:

Programmer, when asked by a manager to volunteer to talk to a job applicant: “Why don’t you do it yourself? I’m not going to do your job for you. If you were better organized, you wouldn’t need to ask me such things.”
Customer, when project manager asks about the possibility of revising the requirements: “You never get the requirements right the first time. If I told you once, I told you a thousand times: Do the job right the first time, then you won’t bother me with revisions.”

How Blaming Hurts A Project

Of course, people are not perfect, so it’s impossible to conduct a large project without occasions on which people cope incongruently. Normal project management can deal with these situations — when they are exceptional. But when the whole environment encourages blame, each new situation further elaborates the incongruence. Fred Brooks once asked, “How does a one-year project get to be two years late?” His answer was “one day at a time.” Our answer is “one incongruent communication at a time,” as the following example illustrates:

One of the developers was developing a module that produced a printed report when it was tested. The manager put a lot of pressure on the developer to be ready on time, with no excuses allowed. The programmer produced the report, and the manager was pleased (though he didn’t show it, of course — it was “just an expected part of the job” in this blaming culture). A month later, other people tried to use this module and discovered that it was not finished after all. The developer had used a word-processor to produce a fake report that looked just like a correct test report should look. He thought this would buy him time (it was a month, after all, until anybody found out) to finish the module. Unfortunately, since he was in over his head, a month wasn’t enough time.

The manager blamed the programmer. The programmer said nothing, because in this culture of blame, saying something only brought further streams of blame down on your head. The person who reported this incident said that in this organization, failure is not allowed under any circumstances. People who have problems in a project and can foresee slippage are unable to cry HELP! and receive appropriate assistance. According to the managers, each programmer is responsible for meeting the deadlines that the programmer agreed to. Inaccurate estimation is “not allowed” and perfection is to be achieved from day one — otherwise you are put in the pillory of blame. In this situation, fake test reports are the rule, not the exception (Akita’s note: to be clearer, replace ‘fake report’ with any of those ‘hacks’ we commonly see in code.)

Blaming is the dark secret underlying the failure of many projects. A blaming culture hurts a project in at least six major ways:

1. People commit to plans they know they cannot achieve, at least to delay blame. (Akita’s note: have you heard that programmer who always seems to have “too much to do, so I can’t even do things right, let alone help others”. The paradox: how can they “have too much” if they themselves agreed, every time, to what to do?)
2. People hide facts that managers need to control the project, as in the above example. (Akita’s note: remember, “having no problems is a problem”, which means things are being swept under the rug.)
3. When problems are finally revealed, people avoid coming forth with creative solution ideas, for fear they will be blamed if the ideas don’t work, or simply appear dumb at first glance.
4. In day-to-day operations, a major portion of everyone’s effort is devoted to positioning themselves so they will not be accused when the time of reckoning arrives. (Akita’s note: example: “the other team is to blame, it’s not my responsibility, or not just mine.”)
5. Those people who somehow feel safe enough to focus on the job at hand find themselves spending large amounts of time checking up on the reliability of others’ communications.
6. People feel bad most of the time, and spend a lot of time fiddling with unproductive tasks or simply staring at the walls.

What Incongruence Looks and Feels Like

Organizations can be changed from a culture of blame to a culture of congruence. To make this change, the first step is measurement, or at least detection — but how to measure blaming? Actually, an experienced consultant can detect a blaming organization within a few minutes of contact, because symptoms are everywhere. Indeed, people within the organization already know it’s a blaming culture — but of course within a blaming culture, blame is undiscussable, and moreover, the undiscussability is also undiscussable. Paradoxically, the existence of undiscussability makes blaming easy to detect. The manager of one project issued a memo saying that there would be no more discussion of project morale, and that he would entertain no questions on the subject because everyone should be grateful to be working on such a terrific project. This could happen only in a blaming organization.

Executives

A culture of blame usually starts at the top. Members of the top level of management are inclined to see the other people in the organization as the source of all problems. The employees are seen as “ungrateful” for the jobs, pay, benefits, and opportunities management has bestowed on them. They are seen to “lack an appropriate work ethic,” “not know the value of a dollar,” “have authority problems,” and “resist change.” These perceptions leave upper management in a predicament: “Do I fire them, or do I fire the people who hired them?”

Such managers feel that they are trying to realize a vision without getting the necessary support, which leaves them out on a limb. The internal kinesthetic experience of these executives is normally a dull and chronic headache — unless the profit margin is really down. In that case, they have more acute feelings, like pain in the chest and burning in the gut. Their low self esteem reflects outwardly in the form of frequent downsizing, re-engineering (Akita’s note: those who, instead of facing problems, keep finding the next fashionable “methodology” to implement, thinking that will solve something), avoiding serious problems, futile memos, and, of course, humiliating of subordinates (Akita’s note: those who left their sub-manager working, thinking they were doing the right thing, and only receive negative feedback months later when it’s convenient — which is a form of humiliation). Towards themselves, they often practice addictive and self-destructive behaviors (which cannot be discussed, but are always the subject of gossip).

Middle Management

When the top leadership is incongruent, middle managers constantly receive mixed messages. Project managers are told of their importance, then find that their seniors have bypassed them to intervene directly in projects or change the rules without consulting them. They feel as if they are living on a roller coaster — unable to predict whether a particular day or week will be an upper or downer. After being publicly humiliated a few times, they decide their best strategy is to try to stay out of trouble by not ever rocking the boat (Akita’s note: and here begins the routine of the conformist clock-puncher). Even though they cannot perform at their best, they try to appear important and extremely useful.

In the blaming organization, top managers try (perhaps unconsciously) to teach their middle managers their own blaming attitudes. When one project manager complained of her inability to get the developers to work faster, the Vice-President of Development said, “If your dog won’t jump high enough, get a bigger stick to beat it with.” Living in hail of such incongruence from above, middle managers’ survival issues stay close to the surface. As they did when they were children, they figure out how to either appease, please, or avoid the power owners. By so doing they insure their survival — and pass the blame on to lower levels.

Employees

At the bottom rung of a blaming organization, employees are usually looking for someplace else to work unless the company is in a stable condition with little competition — or if their retirement is within view. The way to survive is to hide out and appear only to pick up a regular pay check (Akita’s note: and in times of automatic deposits, not even that).

Employees are discouraged from thinking creatively — new ideas are interpreted as blaming the management or attempting to usurp their power and prerogatives. Employees are not rewarded for industriousness — but they are frequently punished for perceived “laziness.” Employees cannot seem to find their managers — except when there are problems. Then, the major efforts are directed as attaching blame rather than solving the problem at hand.

The style of blaming varies from organization to organization. It can be harsh, vindictive, direct or indirect — but it is always contagious. Some organizations have polished their blaming style to a high degree of subtlety — without raised voices, merely by a look, or a memo, or an e-mail message, or a phone call, or a visit if things are really bad. In other organizations, the blame is loud, angry, and frequently done in front of an audience of peers — ensuring that all get the message of who is right, who is good, who is in charge, and who should become invisible.

In such an environment, defensiveness becomes pervasive. To those without formal power and authority, it seems that those with power really don’t care about them — and would banish them with no feeling at all. Thus they feel justified in retaliating (in advance, and in secret), and in avoiding their managers and their problems.

Regardless of the style, blaming from the top always generates fear, malaise, errors, accidents, and passive-aggressive responses from the bottom. Those on the bottom feel small and act from a place of powerlessness. The lack of emotional safety effectively erodes the trust level and makes any attempt at congruence extremely risky. This environment sounds awful and it is — both for the person who has regressed into emotional immaturity and, sadly, for the person at the top who is doing the blaming.

Those on the bottom of any large organization can easily come to feel a sense of dependency on those above them in the hierarchy. When blaming is the primary mode of dealing with people, this dependency is exacerbated (Akita’s note: almost like Stockholm Syndrome). Then, out of a feeling of dependency, people easily generate a feeling of hostility. As this hostility grows so does the debilitating experience of shame — that overly critical judge that lies latent in all humans.

What Congruence Would Look/Feel Like

Most people who have experienced a congruent organization won’t tolerate the misery of working in a blaming organization. But many people haven’t ever had that experience, and have a hard time believing what a congruent organization is really like. Let’s look at what would happen if a healthy dose of congruence could be magically applied on a large scale to an incongruent project organization.

Executives

If we could magically install congruence in the internal programs of those blaming executives, their style would shift dramatically. For example, if they would truly consider the others involved in their communication, they would be more likely to believe in the intent of people to contribute, to be productive, to belong, and to learn — and would take deviations from this ideal as evidence of ineffective management. Their belief in the inherent value of all people along with a healthy respect for the constraints of the work context would engender energy, hope, appreciation, understanding, and gratitude among their employees.

An executive who truly does not believe in the good intentions of the employees will be likely to say, “No excuses! You will get this done on October First.” But, with employees whose intentions are bad, this style (or any other style) isn’t really going to work.

A congruent executive who truly does believe in the good intentions of the employees will be likely to say, “We need this badly by October First. What do you need from us to help get it?” This kind of mutuality and support enlivens a genuine “can do” feeling that increases the chance that a project meets its goals — and that nobody has to make false promises to escape abusive blaming.

When the top level managers sustain their commitment to congruence, they see that most workers appreciate the opportunity the business provides them in developing skills, meaning, relationships, and monetary rewards. They also know how to cope when the occasional worker doesn’t seem appreciative or even productive. Managers who know how to use their power congruently generally get the results they seek — not perfection, which they know not to expect.

These leaders know they have a special kind of power — power they use with awareness and sensitivity. They do not resist accountability to those they lead, but demonstrate the same level of integrity they seek from others. And if they cannot match the levels of commitment they request from others, they are open about that. They know they are sometimes going to be weak and vulnerable and need support — perhaps even to see the value of their own visions. They use their awareness of this human reality to nurture their capacity to empathize and to have compassion for themselves and others.

Congruent executives know that their principal job is developing their organization’s capability, not just pushing the same old shoddy products and services out the door. They involve themselves seriously in organizational improvement efforts while simultaneously involving others in the organization to ground these efforts in real-life, practical operational input and decision making. They know that synergy is needed for organizational development, and they know that synergy comes from high quality connections among people — regardless of level.

Middle Management

When the top folks begin to operate from congruence, the middle managers receive direct, clear messages — not mixed messages with double meanings. Communications are more open, making it easier to know more about what’s really going on. Given higher quality information, they know more about how to be useful, so they can more easily join their leaders in their visions. Knowing more clearly the strategic directions desired and feeling that they count in this process frees them to contribute more generously and thoughtfully — rather than merely playing safe. Success becomes a goal that all can share.

Given their unique vantage points, middle people have useful input to assist in predicting problems, projecting realistic time lines, and forecasting trends. What they see, hear, think and feel is valued, and they are in a position to initiate behaviors that prevent project weaknesses from growing into project failure. They know the necessity of interdependence, so if major problems do develop, they can be counted on to provide — and seek — truthful information. They are not ashamed or afraid to work for those who employ them. Indeed, they have pride about their commitment to the organization — and know it is a commitment not so much to schedules and budgets, but to the truth about schedules and budgets.

Because congruence at the top trickles down, middle managers take notice of the difference in their leaders. They respond to the modeling by passing it on to their constituencies. Everyone in the organization knows what is at stake in doing each job well, so everyone feels safe to tell what is wrong, what is getting in the way, and what is needed to fix it. Honest reporting of facts and feelings is genuinely appreciated, and does not put people at risk of being humiliated or losing their jobs. That’s why congruent organizations deliver their projects as promised.

Congruent middle managers encourage high quality communication. Their belief in people’s ability to learn and change towards more congruence makes those around them responsive. With congruence radiating from the center of the organization, everyone can have a place, position, and function of importance and value — so things get done, and done right.

Employees

Working at the front line of a business where the top leadership is congruent is entirely a different experience from working in a blaming organization. Commitment and energy are the norm, not the exception practiced by new employees until they “learn the way things are around here.”

Congruent organizations hold to an ideology that doing well in the marketplace is connected to doing well with employees as well as with customers. The perspective of the leadership includes a global consciousness about the existence of multiple non-linear factors, the importance of connections among all the various parts of the whole, and the necessity of all parts knowing their value. Workers feel that this is a company going somewhere, where growth is a natural state and everyone’s efforts count. (Akita’s note: this is the seed for self-managing teams.)

Workers in a congruent organization tend to have a long range view and can usually maneuver as needed to meet the changing needs of clients and customers. Employees trust that what they see and hear is real. They share in the enthusiasm of creating a future. They may not like everything that happens — for instance, they don’t always feel that they are rewarded adequately for what they give — but they don’t feel that there is a chronic pattern of undercutting, diminishing, discrediting, and devaluing them and what they do. They can risk congruence knowing that it will act as a catalyst for optimizing successful outcomes that benefit everyone.

Congruence is the bright secret underlying the success of many projects. A congruent culture helps a project in at least six major ways:

1. People commit to plans only after open negotiation, so plans are more likely to be realistic in the first place. (Akita’s note: the team commits only to what they genuinely believe they can deliver, so “I have too much to do” doesn’t exist.)
2. People come forth readily with facts that managers need to control the project, as soon as they are known, so managers can act early and act small to correct the problems. (Akita’s note: agile culture that embraces change.)
3. When problems are revealed, people readily come forth with creative solution ideas, increasing the chances for quick and effective solutions.
4. A major portion of everyone’s effort is devoted to getting their jobs done, and helping others get their jobs done.
5. Because human fallibility is considered normal, an appropriate — but small — amount of time is spent assuring the reliability of communications.
6. People feel good most of the time, and thus are productive most of the time.

Congruence in Large Systems Development Efforts

In the course of developing systems, people engage in numerous acts of communication — about requirements, schedules, interpersonal problems, designs, progress, and just about anything else. That’s why effective individual communication is important in all projects, large and small. That being said, effective communication becomes even more important as the size of the development effort grows. The number of necessary communications goes up non-linearly with the size of the project, so the effect of imperfect communication style is magnified. Thus, if the quality of individual communications remains fixed while the project grows, the overall quality of communication will go down. (Akita’s note: the number of connections between pairs grows according to a Power Law.)

For instance, a certain level of congruent communication might be adequate for producing a product with 25,000 lines of code, yet be totally unacceptable for a product with 2,500,000 lines of code. In order to develop larger and/or more complex systems, then, it’s not sufficient to pay attention to technical issues — accepting that the existing communication style will be adequate. Managers must also improve the project’s communication culture, and thus they must pay more attention to congruence.

To make matters worse, unless we manage well, tougher projects tend to diminish congruence — because stress tends to rise when the expectation of quality rises. We are not always utterly logical creatures, but have feelings as well as thoughts in response to tougher assignments. When these inner feelings are strong enough, they translate into characteristic styles of coping with the stress. If our characteristic style is incongruent, communications become less effective and the job becomes even more difficult, creating a vicious cycle.

Congruence, of course, is but one of the factors in effective communication — other factors include such things as timeliness, memory, proper audience, and accuracy of data. But without congruence, your efforts to improve these more “logical” factors will always be seriously undermined, along with your ability to build bigger, more complex, or more reliable systems.

Achieving Congruence

When Deming said, “Drive fear out of the workplace,” we think he was talking about changing the blaming organization to the congruent organization. This kind of change is made by one person at a time — hopefully starting at the top — and one step at a time. The steps can be broken down into six ‘A’s’, as follows: Awareness, Acceptance, Authorship, Articulation, Application, Activism. Let’s look at how each of these steps takes place in the context of an individual trying to change a blaming organization.

Awareness

Awareness says, “This is happening. This is real.” Awareness comes from experience, when I allow myself to experience the world around me as it is — not as it is supposed to be, or I wish it to be, or someone else tells me they want it to be.

Awareness is always the first step, and probably the hardest, because generally we’re not aware that we’re not aware. Here’s a personal example of how lack of awareness stops the change process before it can even start:

Jerry was attending a project meeting in a software company — a meeting called by the company President to find out what was going on in a late project. After some coaxing, one of the developers said that she was afraid to go to Nat, the Development Manager, with problems, because of the reception she got. Nat got red in the face, stood up, and shouted angrily, “How can you say that? My door is always open to hear your problems! The only thing I won’t tolerate is if you’re all emotional when you come, or if you don’t have a proposed solution!”
In the calmest voice he could manage (it’s hard to stay calm when someone is being so angry, even if it’s not directed at you), Jerry turned to the President and asked if Nat ever came to him with problems. When the President said yes, Jerry asked if Nat was always calm and carrying a proposed solution. Before the President could answer, Nat interrupted: “Why would I come with a problem if it wasn’t important enough to get excited about? And, if I had a solution, why would I come to him?”
Although it was now clear to everyone else in the room that Nat was demanding that others “do as I say, not as I do,” he was unable to see the incongruence. Lacking awareness, there was no way Nat was going to change — and indeed he never did change, up to the time the President released him to seek greener pastures.

Nat’s case is quite typical. Since incongruence is a defense, incongruent people erect all kinds of shields that close off information about congruence. Their own incongruence, and that of others, is invisible — it is accepted, especially if it is the norm in the organization. This invisibility makes it very hard to reach them with any kind of information on the subject.

In other words, when you’re being incongruent, you’re losing your ability to take in what’s going on in the world (inner or outer). So, you don’t know that you need changing. And, even if you did, you haven’t a clue what to change to. No wonder it is so difficult to transform an incongruent culture, when the very first step — awareness — is so hard to come by.

Awareness comes from experience, when you allow yourself to experience the world around you as it is — not as it is supposed to be, or you wish it to be, or someone else tells you they want it to be. But in the blaming organization, where people shield themselves from experience, becoming aware usually requires help. Helping others become aware takes the skill to develop safe environments and to build relationships. It takes the patience and caring to watch for signs of awareness and help build on them. It also takes a belief and a commitment that “part of my job is to help the people on my team to develop — the most important part.” If you don’t believe this, then certainly don’t try to help people become aware. Otherwise, you’ll find yourself saying, “You aren’t aware of what a lousy employee you are, but I’m going to make you be aware!”

But awareness of the overall situation is not sufficient — you also need self-awareness. Self-awareness says, “This is me. This is mine.” You may be fully aware of the blaming, but as long as you merely say, “This is a blaming organization,” you’re not doing anything to change it. When you say, “I am a part of this blaming organization,” you move forward. You own the blaming as a part of yourself and your behavior — not just something that “they” do (to you).

Self-awareness is often followed by depression or shame or guilt. Some people react with anger, at themselves or at any convenient target. Yet self-awareness is empowering — the thought that since I own it, it’s mine to do something with.

Acceptance

Acceptance moves the change process beyond self-blaming and says, “I’m not a bad person because I do this. My intentions are good, though my actions may not be effective.” Acceptance means that you understand that taking responsibility is not the same as blaming yourself. Thus, you have mercy on yourself and your all-too-human imperfection. You stop being angry. You forgive yourself for not doing better in the past, based on your present understanding and standards. And, as you forgive and accept yourself, you gain compassion for the others involved — thereby increasing the chance that you can communicate with them and effect change.

At the point when you’re trying to reach acceptance, it’s critical that you not be punished or humiliated by someone else. You need a little help in getting off your own back, or else you think so little of yourself that you couldn’t possibly do anything about the situation. Of course, in a blaming organization, you may have a hard time avoiding this kind of punishment, which is why authorship and acceptance are usually done internally, and kept internal for some time.

Authorship

Authorship is the first decision point, when you say, “I have choices. I can do something about this.” With some encouragement, you accept that you are responsible for choice in your life. You understand that you don’t have to react, but that you can choose your response — that you create, in large part, your own interpersonal context. You know there are some parts of the context that you can control and some that you can’t; and you know accurately which is which.

Articulation

Articulation is the public commitment to change, and says, “I’m going public with this (for accountability and support).” Articulation is ineffective if attempted before the prerequisites are in place. If you can’t accept yourself or how you have reflected yourself out to the world, or if you don’t know that you have choices or feel you can gain support for those choices, then speaking out is merely ineffective bravado.

But, when the prerequisites are in place, you cannot be effective by keeping silent — you must decide to speak out. In the process of speaking you transform your inner awareness to another kind of experience. You hear yourself and you notice the response you get from others. You make public, if you will, your self — your mental and emotional position.

Initially, of course, you must seek out safe places to disclose your truer and more honest expressions of your thoughts and feelings. When you become more grounded in the power of your true self then you can seek the kind of support that challenges and confronts you, as opposed to the kind of support that coddles and consoles.

Initial steps of articulating congruence are often awkward. That’s why a responsive and receptive listener satisfies one of the requirements for promoting the development of congruence.

Application

Application says, “These are my choices (my new ways of coping).” You learn to be congruent yourself, first in your most immediate, safe, and encouraging context. Then you expand the contexts in which you can respond congruently. Don’t try to “not be incongruent.” This paradoxical command only invokes the incongruence of perfectionism. (“If I can’t be perfectly congruent all the time, I’m worthless.”) Focus on congruence, practice congruence, and the incongruence “muscles” will simply atrophy.

With support and practice you can begin to use and test out congruence in your immediate relationships. We suggest that you continue to design for success, so that initially these tests of your new skill are done within environments where you will more likely be given the benefit of the doubt. As you experience success, then you can be centered even in more turbulent and conflicted arenas. In other words, once you “get the call,” don’t march into the president’s office and announce that henceforth, all the guilty parties must stop blaming, or else.

Activism

Activism says, “Now that I can make a difference in myself and my most familiar world, I’m going to help spread this throughout the organization.” Activism is applied leadership, starting at the point at which you have enough competence at being congruent to reach out and be proactive — anticipating, initiating, instigating — but not inflicting. You cannot operate from an incongruent position and force other people to be congruent. (“I have to blame them, because they’re so blaming. Once they change, then I’ll be able to change.”)

In any case, you don’t have to inflict congruence on anyone. Congruence is contagious — when directed consciously to creating a safe, nurturing, productive environment. It may spread more slowly than you’d like, but once it starts moving, it’s hard to stop.

Either way, the post on the Signal vs Noise blog shows the status of the translations from other countries. I’m proud to say we are WAY ahead: most of them are still on the first chapter. We already finished translating all 16 chapters and we’re halfway through the review.

Which is why I called it “Release Candidate 2”. RC1 was a restricted release, RC2 is public, and in a few days we’ll try to ship the final version!

Thanks to the translators: Herval Freire, Juraci Krohling Costa, Marcello Rocha, Diogo Bispo, Adriano Mitre, Ricardo Augusto, Rodrigo K.

And also to the reviewers: Mateus Del Bianco, Diogo Bispo, Davis Zanetti Cabral, Gustavo Cardoso, Ricardo Augusto.

(Hope I didn’t forget anyone :-)