> 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.
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.
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.
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.
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.
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 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. 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.
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”
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?!"
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)
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.
Yeah? A very basic process, most people use some variation of this implicitly without talking about it.
This sounds like a slightly narcissistic manager who thinks people are doing it wrong if they don't act like small copies of him. There are multiple ways to reach the same outcome and a lot depends on your information. E.g. I typically have a mental model of a system in my head, meaning when some problem needs fixing very likely I already know where it would need fixing and already think about the various future implications arising from a different fix. A point that is totally absent from that framework.
Being a senior dev myself I have seen enough good software turn bad to know that seemingly innocent technological decisions can come with huge and lasting implications. The fact that this is missing here is speaking volumes about the lack of experience at display here.
Your task as a manager isn't to create small copies of yourself. Your task is to know each persons weaknesses and strengths and compose the work in such chunks that the weaknesses have little effect, while the strengths multiply. For this you will first of all have to trust your people and lead them to discover certain ideas themselves.
E.g. if you feel someone always jumps gun-ho I to the task without doing the research, just tell them to give you the research first. Do that a few times and they might realize how useful that is.
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.
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.
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.
> 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
How else would you describe iteratively solving problems?
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.
Just not about your performance review.
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.
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.
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. 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.
“then ask Claude to do it fast with no mistakes”
(edited for accuracy)
How about you stop taking things so personal instead and let others steer more.
I think you're wrong. I think it's embarrassing. Though I might be wrong.
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?!"
I prefer being right, but to each their own.
and do all of it with urgency (magically managers want everything done with urgency)
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.
This sounds like a slightly narcissistic manager who thinks people are doing it wrong if they don't act like small copies of him. There are multiple ways to reach the same outcome and a lot depends on your information. E.g. I typically have a mental model of a system in my head, meaning when some problem needs fixing very likely I already know where it would need fixing and already think about the various future implications arising from a different fix. A point that is totally absent from that framework.
Being a senior dev myself I have seen enough good software turn bad to know that seemingly innocent technological decisions can come with huge and lasting implications. The fact that this is missing here is speaking volumes about the lack of experience at display here.
Your task as a manager isn't to create small copies of yourself. Your task is to know each persons weaknesses and strengths and compose the work in such chunks that the weaknesses have little effect, while the strengths multiply. For this you will first of all have to trust your people and lead them to discover certain ideas themselves.
E.g. if you feel someone always jumps gun-ho I to the task without doing the research, just tell them to give you the research first. Do that a few times and they might realize how useful that is.