207 comments

[ 0.35 ms ] story [ 46.4 ms ] thread
[flagged]
sorry, but when you reach certain levels of influence, you need to slow down, be more methodical, and not be so flippant
Nothing more annoying than a manager with a personal know-it-all framework requiring people to follow it or else they get "feedback".
Author here. This isn’t the one true framework, but it is the one I use. The goal of this post was to communicate to the team the way I think. There are many ways to think and there isn’t one that is more correct than others.

The word “feedback” might be overloaded here also — if you haven’t worked in a culture where feedback is an honest, no-blame part of the culture, then I can see how the idea of giving feedback can feel like a disingenuous corp-speak way to make a person fall in line or have their career impacted. There’s also an inherent power dynamic in giving feedback. However, if the work culture celebrates feedback as an honest way to have more direct conversations, and makes coworkers feel psychologically safe talking to one another directly in this way, it is something that makes culture better for everyone and gives better results in the end. I have given feedback to many people, and I have received it in turn many times.

Also, I am an IC, not a manager.

Thanks for sharing and engaging with the comments.

> Also, I am an IC, not a manager.

I think this understates the power dynamics involved. At your level, being an IC doesn’t mean you aren’t in a leadership position, and feedback from you can still carry substantial weight.

Psychological safety is a worthy aim, but it cannot be assumed, nor will everyone experience it equally. I’d be wary of relying on it too heavily here.

> There are many ways to think and there isn’t one that is more correct than others.

Charlie Munger once said "The right way to think is how Zeckhauser plays bridge. It's just that simple." He managed to boil it down to a single way to think. You disagree?

> The goal of this post was to communicate to the team the way I think

For that you use internal communication channels.

Though we've known for a while that no one at Anthropic is capable of doing any proper communication.

I appreciate you took the time to answer my post. Since you like honesty, let me say that I think your framework isn't terribly useful and, for most people, somewhat condescending coming from people in a leadership capacity. There's nothing wrong with your advice, but it's kind of generic, like "in order to think, you have to think".

I've worked in this culture. I was an IC, tech lead, lower and upper management in medium to large AAA tech companies, household names, that had the same sort of feedback focus.

I think the all-in feedback culture is overall a net negative because it invites this kind of micro-criticism, rules-driven feedback sharing.

Given that, all I can say is that while you're appear to be well intentioned, I would share your framework once or twice and stop pushing it, assuming you're doing that (it sounded like it). I can see most people being annoyed but this kind of framework and that's why my reply was so upvoted.

Quick feedback: this framework feels like a not so well thought out extension of polya’s how to solve it to “do things fast” in a credible looking way.

Harder feedback: the writeup feels like a quickly hacked together memo, which claims it is “self healingly” good. Because it has this throwaway quality I’m not sure what is the goal? Shall I engage with it seriously, when the lead dev didn’t seem to put in the effort? But if I don’t engage with it seriously it means that I have to follow this patchy fremwork?

I can't say I agree with forcing your team to use your own personal "framework" of approaching a problem or else you'll get "feedback".

> Sometimes I will give feedback to people when they are missing steps in the framework, or are poorly executing some of the steps. I expect the same feedback in return.

I also don't like that urgency is built in as the standard process either, no wonder everyone is burnt out.

> 6. Act with urgency to achieve the goal

But if you don't only surround yourself with people who think exactly like you, how will you ever recruit an army of yes men and women?
It’s basically OODA loop, which is itself just as descriptive of how people act and adjust than it is prescriptive.

How else would you describe iteratively solving problems?

Interestingly enough the problem with most of problem solving is identifying the right problem to solve.

It may sound weird but OODA starts making sense once you’ve identified the right problem to focus on.

In its original definition it was based on dogfights. There, your problem is clearly defined.

These steps, but in many other arbitrary orders, some with feedback to previous steps
Acting with urgency is a bit at odds with discovering flaws in your plan. If you're sprinting you're less likely to notice smells and things that are inelegant, more likely to paper them over. That said, there is a time for urgency. Just not every single task.
> I can't say I agree with forcing your team to use your own personal "framework" of approaching a problem

Is that not prt of what leadership always is? It might be less explicit. People often don't write their process down. Things get more confusing because people don't understand what is being asked of them.

But when is there ever no process that has to be followed? What leader lets people do whatever however and what's the role of that leader?

It is called micromanagement when the boss tells you _how_ you should think. My approach is when leading a tech team to find together the things which should be done and find a method together to keep us on the path. Facilitation. Forcing decisions to be made. Keep quality high enough. Let people find what they enjoy doing and is useful. This is really basic and well known set of tools.
This seems strongly aligned with the Amazon doc-writing and decision making process. I found it to be unusually effective as a business process, and took it with me when I left to my current role.

Making thoroughly informed decisions and iterating on a decision doc before committing to a direction and plan is better than every alternative I’ve ever observed in my career.

The criticism I’ve read thus far on this thread seems unwarranted. I give the same kind of feedback to my mentees when their work product or process could use improvement.

> Making thoroughly informed decisions and iterating on a decision doc before committing to a direction and plan is better than every alternative I’ve ever observed in my career.

My last company did this. It usually devolved into a design-by-committee full of compromises to make various stakeholders happy and often yielded a worse artifact.

It became more effective once people got burnt out on the process and most stakeholders stopped caring and started rubber stamping, allowing the one or two people willing to put in the energy to come up with something coherent.

I worked for AWS for several years, eventually leaving during the big "return" to office push because my geographically distributed team working on a product that didn't exist back before the remote period was told we had a month to either move to one of three cities where our team was allowed to work out of our transfer to a team in our area. My wife had an autoimmune condition that would put her at risk if I commuted, so I asked my manager what processes there were for exemptions, but he literally hadn't been told anything by the higher-ups and that as far as he was aware, there were no processes defined at all and we'd have to just try to talk with HR and upper management to try to figure something out. I didn't think that the company expecting me to rush to figure it out when they were the ones who put an artificially constrained timeline on us to either abandon what we had been working on it uproot our lives, so I ended to just giving my notice a couple of days later instead.

My point here is that companies that love to have extremely formal processes around for to handle technical things are not necessarily less likely to have extremely arbitrary decisions without any process for recourse defined when it comes to how employees get treated. If someone describes a technical process that they say they use for everything that a literal reading seems pretty dubious in regards to things like burnout or micromanagement, I don't think it's that crazy to recognize that the reality is probably at least as bad as the obvious implication. Sure, they're not directly saying "I overwork my employees by imposing short deadlines on everything and I nitpick their processes if they different from my own", but there are enough managers who do act this way that it's kind of hard to think someone who cared about being perceived as saying that wouldn't go out of their way to clarify where the nuance is if it truly exists.

i am pretty sure it would just be "wrong," not "meta-wrong," and given the title, i am giving myself the point.
I am not even wrong.
I, I, I, I, I, I, I, Me me me me me me

This is what happens when you let things get to your head. You work on a (highly inefficient, often broken) piece of extremely basic software by prompting a slot machine and hoping it works. Calm down and stop forcing your shitty framework on employees, you're the most replaceable cog of all.

Unlike me, 56 and yet to be wrong once.
It is a burden all of its own.
(comment deleted)
Steps 1–5 of his framework are increasingly formal ways of saying “figure out what’s going on before doing something,” followed by step 6: “then do it fast”
“let Claude figure out what’s going on before doing something”

“then ask Claude to do it fast with no mistakes”

(edited for accuracy)

That's what it took to finally support Agents.md I guess. Boris had to blog about having made a mistake.

How about you stop taking things so personal instead and let others steer more.

Author here. These are unrelated, just happened to both be the same week.
you can ask Claude to see how much of your process is similar to scientific process.
(comment deleted)
> I love being wrong

I prefer being right, but to each their own.

a foolish consistency is the hobgoblin of little minds
The most annoying thing about this is that the steps are out of order unless the definition of problems and goals are intermixed 1. define a goal 2. understand information and gaps in information 3. define and prioritize the problems to achieve that goal 4. identify potential solutions for top problems and prioritize 5. measure success

and do all of it with urgency (magically managers want everything done with urgency)

there is a missing step: "believe in yourself"
“I am often wrong” is directly from how to make friends and influence people.
Just retire at this point, you don't even have to work.
> Something that people learn quickly when they work with me is that my approach to pretty much every problem is: > ... > 6. Act with urgency to achieve the goal

If everything is urgent, then nothing is. This guy sounds miserable to work for and with. Assuming this is accurate and not just hyperbole, he is essentially saying he has no prioritization skills because everything is urgent. I think most people who have been around the block have worked with people like this, and unbeknownst to them, their coworkers develop a default snooze button associated with most of their requests and projects.

Heavens. Is it possible you're reading into it a bit? He's miserable to work with? From this one blog post?

A more generous read, or, at least the reading I took: "once we (think we) know what we're doing, we violently execute."

So, "boo" on you. This guy sounds awesome.

I disagree, on the principle of "slow is smooth, smooth is fast"
This principle is basically a movie quote, though.
and similarly, the need for slack in software teams
How often do people that make this kind of assertion end up themselves being the ones that are miserable to be around I wonder
> Heavens. Is it possible you're reading into it a bit?

Perhaps, which is why I hedged with the possibility that it is mere hyperbole. However, I think what did it for me was his statement that he provides and expects feedback to anyone not following this recipe, which is at utterly without nuance. Incidentally, you can execute with focus and intention without urgency and arguably be more effective over the long haul.

If someone literally publishes on the internet that they require their employees to act like every problem is urgent, it's not clear why you think we shouldn't take them at their word. It's a pretty common thing for bad managers to expect people to work full-tilt 100% of the time rather than understanding that tends to burn poorly out. I'm honestly not sure how someone could spend a decent amount of time in this industry and not be able to recognize that pattern and have thoughts about how to avoid it unless they just don't really care about it much, so while you're entitled to disagree, it's hard not to get the impression that being so affronted by the parent comment pointing out that the blog post doesn't seem to address the very real pattern of phrases like the article uses being euphemisms for pretty horrible work cultures that you just also don't particularly care about it.

Personally, I've seen far too many talented people in tech be worked too hard for too long by management that either is too clueless or too uncaring to the point where it can take years for their health and happiness to recover not to find it extremely alarming when someone says stuff like "everything is urgent". The likelihood that they mean pretty much exactly what they say rather than mean something more nuanced is high enough that the fact that don't seem concerned about the implication says more than enough.

It's not saying treat every problem as urgent, it's saying go through 5 steps that are defing the problem correctly then treat it urgently.
I don't see the difference. The idea that every task ends up in a state with an urgent problem to solve during its lifecycle is crazy to me.
Interesting what I found objectionable was his expectation that everyone around him follow his internal process, regardless of its steps or urgency.

Someone who has an ounce of leadership realizes that a team is a puzzle of different pieces of different shapes. You fit them together in varying ways, by observing how their processes and methods and strengths interlock to be greater than the sum of their parts. You do this fractally as you become more senior, and expect people to follow this meta framework rather than some fixed process or way of perceiving. You see quickly the organization takes on different strengths depending on the puzzle underneath them, composed of nonlinear amalgams of unique individuals. You do create protocols for communicating and decision making that are relatively uniform, but you get your grip off of people’s mojo and let them be people, not one of whom is Boris (unless Boris works for you). But beyond building a Postels law structure for communication and decision making, you expect the meta framework to be the way people evaluate their teams and you evaluate your team in the same way.

You eventually need people to shift around and reorg people to the shape of the system (Conways law) based on their strengths and processes that work for them and their teams. If you need the system to be different you organize the people in that way in and expect the system to change to fit (again Conways law).

None of what I read reflects a thinking like this, and I’d prefer to not work with someone who feels their role is to mint out clones of themselves. Further someone who posts about how they are frequently wrong is the first sign of a narcissist that believes they’re actually never actually wrong, but admits they might be misinformed at times. For me, it’s a red flag to avoid.

> Heavens. Is it possible you're reading into it a bit? He's miserable to work with? From this one blog post?

Everything about this blog post makes me think that I don't want to work with him, not just the "act with urgency" claim. The whole idea that he thought this was a blog post he should write and publish makes me not want to work with him.

I think there is a worthwhile idea in this blog post, which is that you should generally not strongly commit to any specific solution to a problem because you will learn new information while working on the solution, and that it is fine to say, "I was wrong; let's take a step back and rethink this."

But if you were to write a useful post about this, you'd focus on how to decide when to change your approach and when to stick to it, because always rethinking your approach can lead to infinite churn without any releases.

This list also makes zero sense. It says to gather missing information after gathering all known information but before defining a problem. How could you even know what information is missing, much less information that is important, without knowing the problem? And if you're to gather missing information, that you somehow know about, doesn't that make it part of gathering known information? The rest of the list is just as dumb. This list is like a middle schooler was asked to come up with a problem solving framework.

This guy is usually all over threads in which he gets to show off his internal knowledge of Claude Code. I'm sure he'll be here after getting clowned.

The entire Bay Area seems like the most insufferable people known to man. These people have zero introspection.

> It says to gather missing information after gathering all known information but before defining a problem. How could you even know what information is missing, much less information that is important, without knowing the problem?

The post’s description of these steps is reasonable IMO. I’d write it as “put in order the relevant information you have” and “find the information which you know you need but don’t have at hand”.

By way of bad analogy, one could imagine writing up a document first off the top of your head, then filling in more of the document based on the documentation of the relevant systems, corresponding to these two steps the author describes.

Eh, the list and post is not really worth debating. Even the ideas of problems, solutions, and goals are conflated. This has just not been thought about deeply enough by the author to be thought deeply about by others. It's typical Silicon Valley pablum.
I'm still thinking about your first para. But in the second para, did you actually mean he'll be cloned?
I assume "clowned" as in "getting clowned on"
Thanks, that had me going.
There are multiple ways to read what the author said. I personally read it as urgency relative to other stages in the lifecycle, not other tasks you are balancing it against. So if you have five things you are slowly shaping into an executable state, with four of those in the requirements gathering/solution shaping phase, as soon as the fifth ticks over into a state where the solution is ready to implement, you should focus on implementing the solution over shaping other tasks.

To me this seems like a viable approach, and one that isn't obviously the correct approach (but what if busy stakeholder X only has time to discuss unrelated task Y 30 minutes from now? Do you still sit down to work on the shaped task to completion?). Choosing this approach isn't without its downsides, so choosing it is a deliberate decision with its own tradeoffs.

> saying he has no prioritization skills because everything is urgent.

It's not just prioritization. If project is no urgent, it's often gets stuck in "let's think this through", "have we considered X", "let's gather alignment", especially at e.g. Google

So "it's urgent, because X" is sometimes the only way for something to happen

> I hope it is interesting or helpful

I think you're wrong. I think it's embarrassing. Though I might be wrong.

And yet there's none of this uncertainty or caution with his posts that then go on to have massive ripple effects because of his position at Anthropic and the marketting related to claude.

I personally have a lot of anger and frustration with many people in the ai hypesphere that are just mindlessly frolicking around without a care in the world, happy to speak into the megaphone offered by masses that are in a rat-race to avoid some AI dystopian hellscape that keep getting painted by these thought leaders... and then going "oopsies... I am just human guys... y so mad?!"

This guy doesn't think deeply about any problem, possibly because he has never had to and probably because he has never wanted to. He would probably make a good residential plumber.
You must not be a home owner because good residential plumbers are definitely out there solving the “hard problems” that techies love to bloviate about every day.
Who said anything about “good” residential plumbers?
Literally the author of the comment I responded to? Do you not know how to read?

Let me deconstruct it for you.

His words: He would probably make a good residential plumber. would probably make a good residential plumber probably make a good residential plumber. make a good residential plumber. a good residential plumber. good residential plumber.

I think someone can follow "good practices" with a team and get to a bad place.

For instance, Claude Code -- who is Claude Code for? Is it for everyone in the world? Well, if you look at the feature velocity, it seems like the answer is intended to be yes ... Claude Code is trying to solve every problem in software development in the world, all at the same time.

So I question the "user model" here.

Here's another thing that is true about Claude Code: it's among the most inconsistent and buggy pieces of software I've ever encountered.

- You can move the cursor with the mouse in the composer, but not in AskUserQuestion?

- When agents spawn subagents, the model name is inherited from the main agent, and seemingly none of the (4! yes, 4!) subagent tools seem to get this right (except for Explore, which seems to be fixed to a weaker model)

- Sometimes, when my usage limit halts, my agents will pick up when it refreshes (within ~2 hours or something) ... other times, nope -- even within the usage limit?

This is a sampling of my own experiences using this thing frequently. Are these sorts of details not important? Maybe not: I'm not at the level of this team, and may never be.

But I think it's a reflection of agentic engineering ... a somewhat embarrassing one, from my perspective. It paints a picture of a team who can't quite get the details right?

I think when people look back on 2025 -- Boris is going to have his name right there in the books ... Claude Code, coding agents -- Anthropic (& Boris + team) made the first move.

But now it's 2026, and people know how harnesses work, and heavy lies the crown.

Having listened to him give a couple of talks I am always struck by how much he talks and writes like Claude code.

I don’t think he farms out all of his writing and talking to LLMs. I don’t think Claude code was trained to emulate him or anything.

I think his “voice” has been filed LLM smooth by years of agent based interactions. He claims Anthropic engineers use an average of 500+ agents a day. They are human interfaces to token generators more than human to human communication. They are picking up the tendencies of their most frequent communication partner.

Unfortunately, I see Claude being wrong often enough that I view it as a faulty narrator. Often helpful, sometimes totally full of it.

And now I subconsciously apply this filter to anything that sounds like Claude.

Makes me nervous that my voice may be becoming that of a faulty narrators.

To err is human.

Higher level thinking has fewer constraints on being wrong than lower level subconscious thinking. Low level stuff tends to have some repetitive and evolutionary basis. Higher level thought tends to be more one off, less evidence based, and more exploratory until we get to the point of being an expert around particular concepts.

A huge amount of human thinking is being a parrot and repeating statements without a deeper understanding. For example when I say 1+1=2 I'm not thinking about it. If I say 638483+949948= calculation is necessary.

So in this, your voice has always been one of a somewhat faulty narrator, LLMs just may be further degrading the quality of the narration.

Left, right, higher, lower, male, female. People love to explain the brain by dividing it in half, or into poles.

Nothing more human than to label, simplify and categorize, even in the absence of higher quality information.

Lets say you have a colleague named Bob. Bob is a pretty good engineer, but he is as confident when he doesn’t know as when he knows.

You can never tell his degree of confidence in his answer. For low-level things he is pretty good but for critical high-level things it is more ambiguous.

You work around this by checking Bob’s work. Having formal verification steps to check what he says.

Now let’s say you meet Bob’s twin brother Bill. Who talks and sounds just like Bob. He makes fairly grand high-level statements that you can neither test nor verify.

How much do you intuitively distrust him?

Bob also knows how to quickly check things with a little bash scripting and tests. Can quickly switch branches to confirm regressions and consult documentation if something requires more information. His twin can also quickly scan for all the common security vulnerabilities in any code, and will do it without complaining as many times as you want him to. I’ve come to trust Bob with code more than any human.
>"They are human interfaces to token generators more than human to human communication. They are picking up the tendencies of their most frequent communication partner."

I see this happening at work, too. All communication and collaboration between engineers has broken down. Everyone is off in their own world of feature work with the only interaction coming at merge time. Really depressing what has happened to our trade.

> I see Claude being wrong often enough that I view it as a faulty narrator.

I'm reminded of <insert-someone-in-your-life-that-generates-friction-here>

"Often wrong, never in doubt"

> I think his “voice” has been filed LLM smooth by years of agent based interactions.

I've wondered this for a long time now: how does one differentiate between your voice getting "filed smooth to match LLMs" or your brain getting "filed smooth to match LLMs"?

After all, if we accept (as the token providers want us to) that evidence of language use as we see in LLMs is evidence of intelligence, then surely the reverse is true - evidence of machine-only language use is evidence of machine-only intelligence.

IOW, it's the LLM talking through you, not you talking through it.

The problem here is that the latest Claude models have gone off the deep end in their communication, and there seems to be neither awareness nor willingness to fix this. "Having your writing and talking turn into Claude is the risk nothing names" or what vapid strange meaningless thing would Opus say.