There is a Buddhist idea that has lived in my head for decades now. The image is simple: a teacher raises their finger to point at the moon. The student stares intently… at the finger.
The teaching isn’t about the finger. The finger is pointing at something. But the student, eager and well-intentioned, has confused the pointer with the thing being pointed at. They are sucking the finger, as Alan Watts put it, for comfort - instead of looking at where it points.
I keep thinking about this because I keep watching it happen. Not in meditation halls. In engineering organizations.
We Are Very Good at Optimizing the Wrong Thing
Engineers are trained to measure. To make things precise. To track. This is a superpower in the right context and a slow-moving catastrophe in the wrong one.
The problem is that almost every useful practice in engineering leadership is a finger. Scrum is a finger. OKRs are a finger. 1:1s are a finger. Career ladders are a finger. Code coverage targets are a finger. Post-mortems are a finger. The finger is real; it has value, and at some point someone designed it carefully to point at something genuinely important.
But fingers are concrete. You can measure a finger. You can report on a finger. You can build a dashboard for a finger. The moon - the actual outcome or underlying concept the practice was supposed to serve - is harder. It requires judgment. It requires you to hold ambiguity. It can’t be automated.
So we optimize the finger. And after long enough, the finger becomes the point.
I’ve done this. More than once.
The Agile Ceremony That Eats Your Team
I inherited a team a few years ago that ran textbook Scrum. Standups every morning at 9:45, retrospectives every two weeks, planning sessions that started on time, and burndown charts updated religiously. The team’s Jira hygiene was impeccable.
The team was miserable and shipping slowly.
When I actually talked to people, the standups had become status theater: three sentences for the PM, delivered without real communication. The retros produced action items that lived in a Confluence page no one revisited. Planning was a negotiation over story points with no connection to what actually mattered. The velocity metric was healthy; the team’s sense of purpose was not.
The ceremonies had been the moon once. Someone put them in place to create rhythm, transparency, and continuous improvement. But they had calcified into the finger. The team was performing Agile instead of being agile.
This is the most common form of finger-worship I see. It’s particularly hard to spot because the ceremonies look like discipline. From the outside, from a director’s report, from a maturity assessment - everything checks out. The process is healthy. The patient is dying. There’s even a name for it: Agile theater - when teams adopt all the motions of agility while optimizing for ceremonies instead of outcomes.
Ask yourself when a ceremony last actually changed something. Not when it produced an action item. When it changed behavior, direction, or understanding in a way that mattered. If you can’t remember, you’re probably managing the finger.
OKR Season as Performance Art
I have a complicated relationship with OKRs…
The idea is genuinely good: write down what matters, make it measurable enough to know if you achieved it, and let teams figure out how. Separate goals from tasks. Think in outcomes, not outputs. John Doerr’s pitch is compelling, and I’ve seen OKRs work. Will Larson’s take on goals and baselines captures the real intent well: goals should decouple the “what” from the “how,” not become a bureaucratic layer on top of them.
But inside most engineering organizations, OKR season has become something else. It’s a quarterly ritual. Six weeks of workshops, alignment meetings, cascading conversations, spreadsheet templates, and final-hour wrangling over whether a metric is aspirational enough. Then the quarter starts, and the team works on whatever they were going to work on anyway (or the next “super important” project that a senior stakeholder pushes in from the side).
The key results - the finger - consume enormous organizational energy. The actual performance shift that OKRs were supposed to unlock rarely materializes.
I’ve sat in OKR review meetings where a team hit 80%+ on every key result, and nobody could tell me whether the product had actually improved for users. The number had become the thing. The thing had been forgotten.
There’s a version of this that’s even more insidious: teams learn to set key results they know they can hit. The ambition drains out slowly. You end up with a rigorous process for measuring things nobody really cares about. The moon is now completely out of view. The finger is beautifully documented.
If your OKR process mostly generates anxiety and alignment theater, it is pointing somewhere. Follow where it points. It usually points at a trust problem, or a strategy problem, or a prioritization problem that OKRs can’t actually fix.
The 1:1 That Doesn’t Do Anything
I believe in 1:1s. I run them regularly, I prepare for them, and I think managers who skip them are making a mistake.
That said, I’ve also sat in enough 1:1s - including ones I ran myself - that were essentially nothing. A status update. A venting session with no follow-up. A polite ritual that both people felt good about completing.
The 1:1 is a finger pointing at something specific: the growth, wellbeing, and effectiveness of a person on your team. When it’s working, the person leaves the room slightly clearer, slightly more capable, slightly more connected to what matters. When it’s not working, it’s just a recurring calendar event.
The failure mode I’ve noticed most is confusing the conversation with the outcome. A manager holds a 1:1, the report raises a concern, the manager listens empathetically, the meeting ends. The manager feels like they did the work. The concern goes unaddressed.
Listening is the finger. The moon is the person actually growing and solving the problem. (And yes, I’ve done this too. The listening feels like the act because listening is where the effort is visible.)
The other version: 1:1s that are entirely about the manager’s agenda. Status, blockers, updates. The manager walks away informed. The report walks away feeling managed. This is also finger-worship, just from a different angle.
After your 1:1s, are the people you manage measurably more capable over time? Are they solving problems they couldn’t solve before? Are they more confident in their judgment? If not, the recurring invite is just a recurring invite.
Career Ladders and the Level Theater
Career frameworks are useful. I’ve helped build a few. Done right, they create shared language, reduce subjectivity, and give engineers a map for their own development.
Done wrong, they create a new game to play.
You’ve seen this: the engineer who spends 18 months optimizing their promotion case rather than doing great work. The senior engineer who carefully documents their “cross-team impact” in language that mirrors the level rubric. The staff engineer candidate who leads exactly the kind of project that happens to be described as a “staff-level initiative” in the framework, regardless of whether that project is the highest-leverage thing they could be doing.
The level is not the career. The career ladder is pointing at something: actual growth, actual capability, and actual impact. The number is a proxy. But the proxy becomes the target, and Goodhart’s Law does the rest: when a measure becomes a target, it ceases to be a good measure.
I’ve managed engineers who were technically underpromoted by their rubric score and doing extraordinary work. I’ve managed engineers who hit every level criteria and were not particularly good. The map is not the territory. The ladder is not the growth. Will Larson documents this well in his piece on promotion pathologies - the recurring ways that level systems develop a life of their own, disconnected from the actual performance they were meant to reflect.
The fix is not to abandon career frameworks. They’re necessary at scale. The fix is to hold them lightly - to remember that when the level rubric says “leads projects with ambiguity,” the moon is actually “comfortable and effective in ambiguous situations”. Not someone who has learned to narrate ambiguity well in a promo doc.
The Post-Mortem That Closes Itself
Post-mortems might be the clearest example of finger-worship in engineering culture.
The original moon: learn from failures, prevent recurrence, and build psychological safety so people share what went wrong. Google’s SRE book describes the aspiration perfectly: a postmortem is not written as a formality to be forgotten, but as an opportunity to make the organization more resilient as a whole.
The finger: a document. A structured template. A meeting with a facilitator. A list of action items assigned with due dates.
The moon disappears very quickly. The finger is what we have meetings about.
I have read countless post-mortem documents. The ones that change anything have a clear owner for the root cause, real organizational will to fix it, and someone who follows up three months later. These are rare. More commonly, the post-mortem document is written, reviewed, stored in Confluence, and quietly forgotten. The same incident happens again six months later. A new post-mortem is written.
We are very good at running the process. The process is not working.
Post-mortem culture that actually learns requires something that can’t be templated: leadership that treats the findings seriously, that changes roadmaps based on reliability problems, and that funds the unglamorous work that prevents the next incident. The document can’t do that. The document is just the finger.
What Mentoring Gets Wrong
This one is personal.
I’ve been mentored well and mentored badly. The bad mentoring had something in common: the mentor was more invested in sharing their perspective than in the mentee’s actual development.
Good advice is a finger. It points at a capability, a mindset, a way of seeing problems that the mentee doesn’t yet have. The moon is the mentee developing that capability themselves - internalizing it, making it their own, and applying it in contexts the mentor never anticipated.
But advice feels good to give. It feels like helping. The mentor leaves the session feeling useful. The mentee leaves with a list of things the mentor would do.
The failure pattern: the mentee keeps coming back with the same types of problems, and the mentor keeps providing answers. It feels like a productive relationship. What it actually is: dependency. The finger is being pointed, and the mentee is staring at the finger.
Real mentoring is less comfortable. It involves sitting with the mentee’s discomfort longer than feels natural. Asking questions instead of answering them. Resisting the urge to solve, because solving trains someone to be solved-for.
I have a mentor who does this better than anyone I know. Early in our relationship, I would describe a situation and wait for his read. He would ask me what I thought. I found this frustrating. (I was there for his opinion, not mine.) Over time I realized what he was pointing at: my own judgment. He was trying to make me trust it. The answer was never the moon. My developing ability to find answers was the moon.
The Diagnostic
Here is the question I now ask myself when I’m running a process, a ceremony, a framework, or a practice that I believe in:
If this process disappeared tomorrow, what would get worse?
If the answer is “the process would disappear,” you’re worshipping the finger. The finger is its own justification.
If the answer is “the team would lose clarity, rhythm, or growth opportunity,” you’re probably still connected to the moon. The process is doing what it’s supposed to do.
The second question: When did this practice last change something? Not produced something. Changed something. Altered behavior, direction, understanding, or outcomes in a way that mattered to someone outside the room.
If you can’t answer that, the practice may have drifted. Not because it was bad. Because practices drift. Because the organization changed. Because what once pointed helpfully now just points.
The Harder Problem
Here’s what makes this genuinely difficult: you cannot see the moon without the finger.
The ceremonies, the frameworks, the 1:1s, the post-mortems - they are not the enemy. They are necessary. A team with no ceremonies has no rhythm. A manager with no framework has no consistency. A mentor with no structure helps no one.
The finger is how you find the moon in the first place. That’s the whole point of the Buddhist image. Without the pointing, you wouldn’t know where to look.
The discipline is holding the finger lightly. Using it as long as it serves and letting it go when it stops pointing at anything real. This is harder than it sounds, because organizations develop immune systems around their fingers. The sprint ceremony has been running for four years. The OKR template is the way we do things. Suggesting that the post-mortem process isn’t working feels like attacking culture.
But the question isn’t whether the finger is legitimate. The question is whether it’s still pointing at anything.
Ryokan, the Zen poet, wrote something that has stayed with me:
Relying upon a finger, we see the moon. Relying upon the moon, we understand the finger.
(The full poem and context from Okumura Roshi are worth sitting with.) The relationship goes both ways. You need the finger to find the moon, and you need the moon to know what the finger was actually for.
Most engineering organizations stop at the finger. The work of leadership - the actual work, the hard part - is keeping the moon in view even when you can’t measure it. Even when the dashboard shows green. Even when the quarterly report looks fine.
Look up from the finger. See where it’s pointing. Go there.