Calibrate Before You Accelerate: Bias Toward Action in a New Role
TL;DR
In a new role, a bias toward action pays off only after you have built context. The author describes phases: first learn how things work and why, then make visible changes. He cites Chesterton's Fence against removing what you don't yet understand.
The article
The article could not be fetched. The tldr comes from the HN thread, and the digest covers the discussion.
The discussion
Most readers agreed with the advice, and several called it obvious, a restatement of Chesterton's Fence. The liveliest arguments were about when a new leader should change a system they don't understand, and whether AI wrote the post. The author said he dictated it and had a model clean it up.
Changing things versus learning them first
One commenter recalled two CTOs, one who changed everything from day one and one who spent months with each team first, and admired the second. jaggederest argued that in a failing, opaque company, small deliberate changes are the only way to learn how it responds. Others countered that a new leader has limited goodwill to spend on changes and must know how to run a business. They added that the metrics a CEO sees describe last quarter and don't predict what a change will do.
The right way to make those changes, or at least one way and I don't know a better one, is to perturb the system and see how it responds. This is necessarily risky and uncomfortable, and choosing the right things to perturb and the magnitude of those peturbations is a very, very tricky skill.
Once people get sick of poorly thought-out changes it can be hard to keep changing things and get buy-in, and talented employees (who almost always have someone asking to hire them) can be the first to leave.
What Chesterton's Fence actually asks
The principle got quoted in full and then argued over. Some read it as a license to leave odd things alone, and said undocumented processes, like Marge calculating penalties by hand, are often the problem. Defenders replied that the fence only asks why something exists before you remove it, and the answer may be that it should go. A side thread named exceptions you remove at once without asking, such as a plaintext password in source control.
The point Chesterton is making isn’t that you leave everything alone. It’s just that you find out why something is there before you take it out.
For example if you find a password in plaintext in source control, you don't assume the person who put it there had a good reason, you assume they were deeply misguided.
Was the post written by AI?
The largest single thread called the prose and the illustrations AI-generated, citing garbled labels like "Witchen" on a blueprint and the phrase "load-bearing". The author said he dictated his thoughts and had a model transcribe and reword them. Critics said polished AI prose no longer shows the author cared; defenders called AI a tool and said the ideas were still the author's. The exchange ended in curt goodbyes.
Author here: I dictated this article into my phone and got a model to transcribe and clean up / reword.
In the 2010s and earlier removing all typos, fixing wording, formatting the text and adding images were all signals that someone put extra care into sending their message. But in the present that just indicates use of AI.
Useful things to do in the learning phase
jedberg runs a listening tour with five fixed questions sent ahead in the invite, then anonymizes the answers into a guide. hinkley starts by fixing documentation, runbooks and CI. That work can't break production, and newcomers are the ones who notice what the docs leave out. Others suggested cleanups and small projects nobody else wants, analysis tools, and announcing small wins so people notice them.
So I always start with fixing the documentation, the runbooks, the CI process. It's a deliverable you can engage in without breaking production, it demonstrates mastery, it fixes a pain point that the more professionally mature members of the team care about, which gets you brownie points with the right sort of people.
Taking on little projects that are already understood, taking on cleanups, things other people aren't volunteering for, is all a great way to find where some of the bodies are buried, understand how the team works, and prove yourself as a team player.
The opposite problem, and the clock
A few commenters warned against reading the post as permission to stall. One had watched managers who never left the learning phase lose their peers' faith. Another said fear pushes corporate developers toward inaction. A burned-out engineer said pressure to ship features during the learning phase makes it hard to learn at all.
It’s critical to start showing some Phase 3 impact, even if not with a sledgehammer, before peers quickly loose faith
Consensus
Learn why things are the way they are before changing them, and spend the first months on low-risk work that builds trust. Many thought this was common sense that didn't need a whole essay.
Dissent
Some argued that you can't understand a failing, opaque organization by watching it, so a new leader has to make deliberate changes to learn. Others warned that waiting too long costs credibility.