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.
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.
>"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. Juniors don't have questions anymore. Seniors don't discuss architecture anymore. Everyone is just off in their own world of feature work with the only interaction coming at merge time. Really depressing what has happened to our trade.
It seems strange to write a blog post about being proven wrong, without a single example of being wrong. Especially with all the current Claude.md drama.
Everyone loves being wrong in the abstract - this reads more like a self-congratulation than a genuine reflection.
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.
> 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?
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.
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.
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.
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”
I still am mind blown at how bad CC is as software. It’s just not that hard of a problem. I get that harnesses aren’t trivial, but they’re not insane either. And the fact that it’s running on a JS runtime (that they bought!) is also crazy. Why not Go/BubbleTea? Why not literally anything native? It makes no sense
I don’t want to be a jackass, but it’s hard to take anything Boris says seriously when he’s headed up such weird software. And it’s not like resourcing or money is an issue for them. If Claude was so damn good, why does CC suck?
I'm surprised you think Claude Code is good software. I find it so hard to use because it is fundamentally constrained as a TUI. It is buggy, clunky and slow. It is sooo slow.
One example of what is particularly bad with it: tool calls and progress. Codex UI does it so much better. The way in which CC waits for a task to complete etc is really poorly done compared to Codex.
Another thing that's missing: no way to continue a side chat in Claude Code - this is easy in Codex with /side and it is super usefu.
I dont't really know stats about such things, but I assume the adoption of CC has been insane compared to almost anything, and is also like two years old? Yeah, not surprised.
But also, if they all use 500 agents daily and latest models can "one shot" everything, one would think 5k issues are fixed in no time...
Havent used CC in some time, worked fine last time I tried.
I’ve rolled my own harness in Go. I have a rule to not let the production LoC exceed 50k lines. It is _very_ nice for my use cases. DeepSeek Flash V4.1 often performs at the level of GPT 5.6 Sol for non-orchestration tasks (programming and maths).
I add features and tweak it all the time: You just need to get comfortable with spending 3 hours in a chat session every 3 weeks to think hard about how to simplify whatever slop you didn’t simplify the last time you did this :)
It is strange how people who say they are "often wrong", never quite sound like they take that into consideration when delivering opinions or thought pieces - I see it fairly often in tech. Anyways; nothing against Boris, but Anthropic/Claude has certainly been the first company (& product) too annoying for me to use.
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.
1) I start to believe my own hype because I am so consistently correct- which blinds me to other ideas if I don't actively take steps to humble myself.
(after all, I won't be right very often if I stop listening, as that's part of why I am right, because I listen to people and have a huge amount of context)
and
2) I am able to quickly come to a conclusion which makes people uneasy, as they think I haven't considered all the points even though I have- and it's also true that people have a bias to inaction unless it's an urgent issue.. this is how things get stuck in committees and meetings and continually get kicked down the road because it's difficult to get everyone together and there's a million reasons to keep deferring meetings.
What I'm trying to say is, don't sit there thinking that "if only I could make correct decisions"- because even if you are quick, correct and decisive: you will ruffle feathers.
(at the risk of sounding arrogant: i'm not saying I'm right about everything, like the red baron, I pick my battles very carefully).
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 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.
I think someone can follow "good practices" with a team and get to a bad place, especially with such a novel product (as AI coding agents).
But taking Claude Code as the product of this style of thinking -- 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, even with the assistance of purported extremely powerful AI tools, even internal ones which we don't have access to?
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.
Heaps of comments here but nobody has pointed out he defined the goal after defining the problem. That's cheating.
Step one is to define the goal. Then you work out how to reach the goal. (Gather information and form a hypothesis) Then you take steps toward the goal. (Test your hypothesis to make sure you stepped in the right direction.)
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)
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.
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.
>"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. Juniors don't have questions anymore. Seniors don't discuss architecture anymore. Everyone is just off in their own world of feature work with the only interaction coming at merge time. Really depressing what has happened to our trade.
> He claims Anthropic engineers use an average of 500+ agents a day.
What are they doing all day with that, I wonder?
Well, trying to make RSI for one so humans don't have to do that work.
LLMs are still a very new technology in relation to human timeliness. There is a whole lot of exploration to be done.
Does that mean 500 separate agents or 500 agent sessions I wonder.
the former
It seems strange to write a blog post about being proven wrong, without a single example of being wrong. Especially with all the current Claude.md drama.
Everyone loves being wrong in the abstract - this reads more like a self-congratulation than a genuine reflection.
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
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.
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?
I'll rent an army of yes agents instead.
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.
and the fun question of how do you find good problems is very hard to systematize!
These steps, but in many other arbitrary orders, some with feedback to previous steps
Nothing more annoying than a manager with a personal know-it-all framework requiring people to follow it or else they get "feedback".
He's often wrong, don't you know.
Just not about your performance review.
> 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.
> 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.
I was literally writing almost this exact post but decided to reload the page first.
How often do people that make this kind of assertion end up themselves being the ones that are miserable to be around I wonder
Developers get triggered about managers breathing down their neck when they read things like this that’s why you get such strong reactions.
I disagree, on the principle of "slow is smooth, smooth is fast"
This principle is basically a movie quote, though.
No it's not, though?
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.
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.
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)
I still am mind blown at how bad CC is as software. It’s just not that hard of a problem. I get that harnesses aren’t trivial, but they’re not insane either. And the fact that it’s running on a JS runtime (that they bought!) is also crazy. Why not Go/BubbleTea? Why not literally anything native? It makes no sense
I don’t want to be a jackass, but it’s hard to take anything Boris says seriously when he’s headed up such weird software. And it’s not like resourcing or money is an issue for them. If Claude was so damn good, why does CC suck?
Claude Code is also offered as an SDK, you can build custom (customized) harness on top of what essentially is Claude Code. https://code.claude.com/docs/en/agent-sdk/overview
I'll be honest, I don't actually understand what people mean when they say Claude Code is bad software.
Seems pretty good to me. Presumably this is about the TUI version?
I'm surprised you think Claude Code is good software. I find it so hard to use because it is fundamentally constrained as a TUI. It is buggy, clunky and slow. It is sooo slow.
One example of what is particularly bad with it: tool calls and progress. Codex UI does it so much better. The way in which CC waits for a task to complete etc is really poorly done compared to Codex.
Another thing that's missing: no way to continue a side chat in Claude Code - this is easy in Codex with /side and it is super usefu.
Do you really think that having this many issues is justifiable/ok?
https://github.com/anthropics/claude-code/issues
I dont't really know stats about such things, but I assume the adoption of CC has been insane compared to almost anything, and is also like two years old? Yeah, not surprised.
But also, if they all use 500 agents daily and latest models can "one shot" everything, one would think 5k issues are fixed in no time...
Havent used CC in some time, worked fine last time I tried.
I’ve rolled my own harness in Go. I have a rule to not let the production LoC exceed 50k lines. It is _very_ nice for my use cases. DeepSeek Flash V4.1 often performs at the level of GPT 5.6 Sol for non-orchestration tasks (programming and maths).
I add features and tweak it all the time: You just need to get comfortable with spending 3 hours in a chat session every 3 weeks to think hard about how to simplify whatever slop you didn’t simplify the last time you did this :)
Turns out he just used what he knew, TypeScript, and not what best solves the problem. He must have not had his "framework" then.
It is strange how people who say they are "often wrong", never quite sound like they take that into consideration when delivering opinions or thought pieces - I see it fairly often in tech. Anyways; nothing against Boris, but Anthropic/Claude has certainly been the first company (& product) too annoying for me to use.
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.
> I hope it is interesting or helpful
I think you're wrong. I think it's embarrassing. Though I might be wrong.
Unlike me, 56 and yet to be wrong once.
It is a burden all of its own.
We all have a short time on this planet. This desire to always have urgency, speed, more money is insane.
Humans are in trouble
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.
Heh, I have the opposite... uh "problem".
I am often right.
This has two negative effects;
1) I start to believe my own hype because I am so consistently correct- which blinds me to other ideas if I don't actively take steps to humble myself.
(after all, I won't be right very often if I stop listening, as that's part of why I am right, because I listen to people and have a huge amount of context)
and
2) I am able to quickly come to a conclusion which makes people uneasy, as they think I haven't considered all the points even though I have- and it's also true that people have a bias to inaction unless it's an urgent issue.. this is how things get stuck in committees and meetings and continually get kicked down the road because it's difficult to get everyone together and there's a million reasons to keep deferring meetings.
What I'm trying to say is, don't sit there thinking that "if only I could make correct decisions"- because even if you are quick, correct and decisive: you will ruffle feathers.
(at the risk of sounding arrogant: i'm not saying I'm right about everything, like the red baron, I pick my battles very carefully).
a foolish consistency is the hobgoblin of little minds
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.
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?!"
“I am often wrong” is directly from how to make friends and influence people.
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.
I think someone can follow "good practices" with a team and get to a bad place, especially with such a novel product (as AI coding agents).
But taking Claude Code as the product of this style of thinking -- 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, even with the assistance of purported extremely powerful AI tools, even internal ones which we don't have access to?
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.
Heaps of comments here but nobody has pointed out he defined the goal after defining the problem. That's cheating.
Step one is to define the goal. Then you work out how to reach the goal. (Gather information and form a hypothesis) Then you take steps toward the goal. (Test your hypothesis to make sure you stepped in the right direction.)
> I love being wrong
I prefer being right, but to each their own.
I like being right so much that, when I'm wrong, I change my mind, despite how embarrassing that is.
7. Reflect on that goal?
Just retire at this point, you don't even have to work.
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)
quick - someone turn this into agentic harness :)
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.
sorry, but when you reach certain levels of influence, you need to slow down, be more methodical, and not be so flippant