Courage is the engineering virtue that every methodology claims to value and no methodology can teach. It is not the absence of Fear. The absence of fear is sociopathy, and sociopaths do not write rollback plans. Courage is the presence of fear and the deployment anyway.
Extreme Programming (XP) is the only software methodology honest enough to list Courage as one of its five core values — alongside Communication, Simplicity, Feedback, and Respect. This is remarkable, because it is an admission that software development requires not just technical skill but nerve, and that a team without nerve will accumulate technical debt, avoid hard refactors, and never tell the product owner that the deadline is fictional. The other methodologies assume courage will emerge naturally from the framework. XP looked at the industry and said: no, you need to put it on the list, in writing, because if you don’t name it, people will optimise it away.
They were right. People optimise it away constantly.
“Courage is a dependency with no package manager. You cannot install it. You cannot pin the version. You can only discover, in production, whether you have it.”
— The Lizard, whose courage operates at such low frequency it is often mistaken for indifference
Taxonomy of Courage
Courage in the software industry manifests in three distinct forms, each with its own risk profile and its own reward structure:
Courage Upward — telling truth to power. This is the rarest and most consequential form. It includes telling the CEO the monkey joke before you have an employee ID, telling a customer’s CTO to give the founder hell, and telling the VP that the migration timeline is imaginary. Courage Upward has the highest potential cost (your job) and the highest potential return (the CEO trusts you for the next four years, the founder photographs your envelope and sends it to California with two words: Please execute).
Courage Outward — doing the thing everyone is afraid to do. Deploying on Friday. Refactoring the module that nobody has touched since 2014 because the person who wrote it left and the comments are in a language nobody on the team speaks. Deleting code. Writing the post-mortem that names the systemic cause instead of blaming the intern.
Courage Inward — admitting you were wrong, you don’t know, or you need help. This form is often dismissed as weakness by people who have never shipped anything under pressure. It is, in fact, the load-bearing form: teams that cannot admit ignorance cannot learn, and teams that cannot learn ship the same bug in perpetuity, each time with a more elaborate workaround.
The Empirical Evidence
The Monkey Joke (Courage Before Day One)
riclib’s first act of professional courage occurred on a bus to a Scottish castle, fifteen days before his first day at webMethods, when he told the CEO — the monkey at the top of the tree — the joke about what the monkeys at the bottom see when they look up.
The CEO said: “Do you know what a Career-Limiting Move is?”
Then he laughed.
For the next four years, that CEO trusted riclib implicitly, because a person who tells you the monkey joke to your face before they even have a desk is a person who will tell you the truth when the truth is expensive. Every CEO is surrounded by smiling faces. The smiling faces nod at the strategy deck. The smiling faces say “great question” in meetings when it was not a great question. The person who tells you the monkey joke is offering to be the one face that doesn’t smile on command.
The career-limiting move became a career-defining one. This is the paradox of Courage Upward: the move that could end your career is often the move that starts it.
“The career-limiting move and the career-defining move are the same move. The difference is the audience.”
— The Caffeinated Squirrel, on the importance of choosing your CEO carefully
The Envelope (Courage Through Engineering the Confrontation)
The fullest expression of courage in the riclib corpus is not a single act but a sequence — a carefully engineered chain of events documented in the Technical Account Manager article, in which riclib told a French CTO to give the six-foot-six Australian founder hell about a terrible Siebel adapter that the product team in California had been ignoring for months.
The customer’s CTO said: “I will not raise the issue. I know you are working on it.”
riclib said: “Give him hell. He can take it. He’s a six-foot-six Australian and people don’t shout at him often enough.”
The CTO gave the founder hell. A director from the local office watched with the specific happiness of a person who expects someone else to be fired after lunch. Over lunch, the founder’s first words to riclib:
“You told him to give me hell, didn’t you?”
Pause.
“That’s why we need people like you.”
The founder asked riclib to draw the solution on an envelope. riclib drew the solution on an envelope. The envelope was photographed. The photograph was forwarded to the product lead in California who had been ignoring calls for six months. The forwarding message, in its entirety: Please execute.
Two words. One photograph. California started answering calls immediately.
This is not simple courage. This is architectural courage — the courage to engineer the confrontation, to arrange the pressure, to put the right information in front of the right person at the right time, knowing that the immediate consequence might be your own termination and the long-term consequence might be the solution. riclib did not shout at the founder. riclib arranged for the customer to shout at the founder, because the customer had the standing, the grievance, and the invoice. Then riclib had the solution ready on the back of an envelope, because courage without competence is just noise.
“Courage is telling the CTO to give the founder hell. Competence is having the solution ready on an envelope. The combination is why California started answering calls.”
— The Lizard, who never needs an envelope because the solution is already visible to anyone paying attention
Deploying on Friday
The Friday deployment is the industry’s standard courage test, and like all good tests, it reveals character.
The argument against deploying on Friday is rational: if something breaks, you will spend your weekend fixing it. The monitoring will page you at 3 AM on Saturday. Your partner will ask, again, whether you actually like this job. The rollback will happen while you are at someone’s birthday dinner, one-thumbing terminal commands on your phone under the table.
The argument for deploying on Friday is also rational: the code is ready now. Waiting until Monday does not make it readier. Monday will bring new context, new priorities, new reasons to delay. The code will sit in a branch over the weekend, accumulating merge conflicts and anxiety in equal measure. By Monday, someone will say “let’s wait for the next sprint.” The next sprint has its own Fridays.
The person who deploys on Friday is not reckless. The person who deploys on Friday has written the rollback plan, checked the monitoring, informed the on-call, and decided — with full knowledge of the consequences — that shipping is better than waiting. This is courage. Not the absence of fear. The presence of fear, a rollback plan, and a deploy button.
The person who never deploys on Friday is not cautious. The person who never deploys on Friday has a branch graveyard where good code goes to die, a velocity chart that plateaus every Thursday, and a Monday morning standup where they say “I’ll deploy this morning” and then don’t, because Monday has its own reasons to wait.
“I deploy on Friday because Monday is a lie we tell ourselves. Monday has its own Fridays.”
— The Caffeinated Squirrel, who deploys on all days because every day is a day that ends in caffeine
XP’s Confession
Kent Beck listed Courage as one of XP’s five values in 1999. This was a radical act.
No other methodology lists courage as a value. Scrum lists Commitment, Focus, Openness, Respect, and Courage — but Courage was added later, almost as an afterthought, and it is the value that Scrum Masters mention least in retrospectives because it is the value that cannot be addressed with a sticky note. You cannot write “Be more courageous” on a Post-it and put it in the action items column. Courage is not an action item. Courage is a disposition.
XP listed it first, and XP meant it. The courage to refactor code that works but is wrong. The courage to delete code that someone spent three months writing. The courage to say “I don’t know how to do this” in a planning meeting. The courage to pair-program with someone better than you and learn instead of performing. The courage to write a test that you know will fail, because the test is telling you the truth and the passing build is lying.
XP’s five values — Communication, Simplicity, Feedback, Respect, and Courage — form a system. Remove any one and the others degrade. But Courage is the keystone. Without courage, Communication becomes politeness. Simplicity becomes avoidance. Feedback becomes compliments. Respect becomes deference. With courage, they become what they were meant to be: honest, clear, direct, and useful.
“XP is the only methodology that admits you need nerve. Every other methodology assumes the framework will provide it. The framework does not provide it. The framework provides ceremonies. Courage is not a ceremony.”
— The Lizard, who predates XP and considers all methodologies temporary
The Fear Relationship
Courage and Fear are not opposites. They are co-dependents. Fear without courage is paralysis — the branch that never merges, the conversation that never happens, the deploy button that never gets pressed. Courage without fear is recklessness — the deploy without a rollback plan, the truth told without regard for timing, the refactor that touches every file in the repository on a Friday afternoon.
The productive state is both: fear that understands the consequences, and courage that acts despite them. The rollback plan is not the opposite of courage. The rollback plan is what makes courage possible. You cannot be brave if you have nothing to lose. You cannot be brave if you have no plan for losing.
The distinction matters because the industry conflates courage with confidence, and confidence with competence. The confident person says “it’ll be fine.” The courageous person says “it might not be fine, here’s what we do if it isn’t, and I’m deploying anyway.”
Measured Characteristics
XP values that are also human virtues: 1 (Courage)
XP values that are process characteristics: 4 (the others)
Methodologies honest enough to list Courage: 1 (XP; Scrum added it later, reluctantly)
Career-limiting moves that became defining: at least 2 (the monkey joke, the envelope)
Days between monkey joke and first day: 15
Words in the founder's forwarding email: 2 ("Please execute")
Items drawn on the envelope: 1 architecture diagram
Months California ignored calls (before): 6
Minutes California took to call back (after): <60
Friday deployments (industry average): low
Friday deployments (courageous teams): same as any other day
Fear required for courage: >0 (at 0, it's not courage — it's something else)
Rollback plans written by courageous people: always
Rollback plans written by reckless people: never
Sticky notes that can teach courage: 0
See Also
- CEO — The person you need the most courage to address honestly. The good ones will laugh at the monkey joke. The others will ask if you know what a career-limiting move is, and mean it.
- Technical Account Manager — The role that requires courage as a daily operating expense: calling the scary COO, engineering executive confrontations, drawing solutions on envelopes while your continued employment is uncertain.
- Career-Limiting Move — The move that everyone warns you about and that, when executed with courage and competence, becomes the move they tell stories about in Yagnipedia articles.
- Fear — Courage’s necessary partner. You cannot have one without the other, and anyone who claims to have courage without fear is either lying or deploying to an environment with no users.
