sorry, but when you reach certain levels of influence, you need to slow down, be more methodical, and not be so flippant

He's often wrong, don't you know.

Just not about your performance review.

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 and childish, like "in order to think, you have to think" with a hint of "move fast" corporate drivel.

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 at most 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'll rent an army of yes agents instead.

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

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?

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 not even wrong.

7. Reflect on that goal?

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.

It is a burden all of its own.

“let Claude figure out what’s going on before doing something”

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

(edited for accuracy)

you can ask Claude to see how much of your process is similar to scientific process.

I like being right so much that, when I'm wrong, I change my mind, despite how embarrassing that is.

a foolish consistency is the hobgoblin of little minds

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.

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.

I was literally writing almost this exact post but decided to reload the page first.

Developers get triggered about managers breathing down their neck when they read things like this that’s why you get such strong reactions.

No it's not, 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.

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.

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 assume "clowned" as in "getting clowned on"

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?!"

Concept of sarcasm will blow your mind.

And since you’re so intent on deconstructing:

He would probably make a good residential plumber.

Him making a good residential plumber≠average residential plumber is good.

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.

What does that mean though? Does it mean there are more than 500 different "agent" systems within Anthropic and employees interact with most of those in a daily basis?

That isn't typically how abstraction is tallied. The ceo doesn't say they use 15k employees, or the programmer uses 30B transistors. Or the director uses 120 workers. You enumerate what you actually interact with.

No, I think the confusion on your part is around what it sounds like when you say "in relation to human timelines". Humans have been here for around a million years. We've been living in cities for several thousand. It sounds like what you're actually comparing to is AI computing to pre-AI computing, which is reasonable, but I don't really see how that is accurately described by "in relation to human timelines".

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.

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. 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.

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.

Turns out he just used what he knew, TypeScript, and not what best solves the problem. He must have not had his "framework" then.

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

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...

IMO, CC should be the poster child of what LLM coding should "feel" like. If things are so good why are there so many issues? Why can't they get a handle like other well-run projects? As you said, they have unlimited tokens so this project should be close to pristine as much as possible.

No one knows how many bugs claude has because Anthropic auto-closes Issues (or at least used to) if there isn't someone constantly pinging the issue every two weeks. I've contributed to several issues that were confirmed by several other people, which were they were auto-closed after people gave up confirming the problem without any response from Anthropic. They seemingly don't care if it isn't on fire or at least smoldering heavily, which seems really bad in my book if you're trying to make even reasonably good software.

Claude Code has /btw which I think is the equivalent of /side in Codex.

it tries but /btw can't be invoked at any time. it is blocked until the reasoning is done. you also can't continue the chat with it

you also can't have tool calls inside it

Harnesses try to solve a wide range of complex, open-ended UX problems, so there isn't a perfect one.

CC might be the best one I've used if I give each major UX aspect a rating 1-5 and then average them. For example, it has a decent subagent viewer.

Meanwhile, Codex doesn't even have one, and its subagent tool call is so buggy that the parent agent sometimes doesn't even know why the child died.

Being a TUI is very limiting, yes, though that limitation isn't the harness' fault.

I've only used the Claude TUI, but it is extremely sluggish. It takes 1-2 seconds minimum to launch on a MBP M4 with 48 GB of memory. I have also encountered plenty of display-related bugs that you can find documented all over the internet. If you had to group this into a software quality bucket, it certainly would not fall into "good". Maybe "mid".

I am in the process of open sourcing it! Unfortunately, my employer requires a (hopefully) cursory legal review.

Small indie company, as the kids like to say.

I would think that with agentic coding they’d be able to have a shared core and an interface native to the system, I.e. not react in the terminal and a swift or C# front end for the desktop app

“Claude, fix my framework (I am often wrong)”

I literally read this as human loop engineering. The next step would logically be to turn this into an agentic loop, and I imagine he does lots of that too.

It's because it's some weird form of virtue signalling/humble brag. Nothing genuine about it.

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).

We all have a short time on this planet. This desire to always have urgency, speed, more money is insane.

Humans are in trouble

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.

Won't anyone think of the bees?

Aha, another iterative improvement variant. (see also eg OODA and PDCA)

I'd argue that Boris Cherny is in fact nearly always wrong;

except when he's right, which is in the final pass just before the work is done. ;)

I think how important this step is something you realize once you consider the alternative, which is trying to fix a problem, without knowing, what the problem is. It is going to result in weird workarounds instead of addressing the actual issue.

Translation: "I'm so wise guys, that I'm using epistemic humility principles to hide it"

Right and wrong are forms of judgement, subject to debate, and sources of resentment.

Correct and incorrect are at least possibly quantifiable and do not intrinsically involve subjectivity.

In other words, my being incorrect is something others can help me to understand and rectify. My being "wrong" is a position which can yield second order harm.

It makes him feel important and smart and powerful.

What a bizarre and frustrating "feature". I was bewildered when that was first introduced. Glad I'm not the only one frustrated by it.

We'd gladly fix the bugs in Claude Code in our own forks but they're too ashamed of their AGI level code to make it open source.

Sorry I meant it's too dangerous to be released.

Only gross incompetence can even lead to the point of users telling them what obvious things to fix.

So what are they respecting themselves for, what do they take pride in? Anything I would care about?

Yeah it's something server side if I recall correctly from the numerous threads, regular messages getting returned as thinking tokens or something strange.

I've got a Claude session going which can check sessions and count how many of these messages I haven't seen due to this bug.

On a similar topic - since you said "I always use" - is it true that nearly everyone at Anthropic is using Fable and that's why Opus 5's style of speech was not really noticed as problematic by Anthropic employees?

Yeah, I feel you here :+1:

I bet things fall by the wayside. The firehose volume is very high.

To be fair, isn't this the standard response to issues everywhere?

No, not really. Anthropic is notorius for ignoring issues, pretending they don't exist, gaslighting and blaming users, then spending weeks fixing things that end up being obvious even to juniors.

At the same time they proudly tell everyone how they don't look at code anymore and only run a gazillion Claude sessions.

Step 1 "Understand the available information" is apparently a hard step.

(I too have been incredulous that this remains an open issue; if this gets it fixed, bring on the boris blog posts!)

Ridiculous CC bug I encountered, that others have encountered as well: I asked Fable to review a commit. Suddenly my Fable quota for the week was at 100%, while a moment ago it was at 55%. A few days pass (1 day before the weekly reset) the quota resets back to 55%. ?!?!?!?!

There’s bugs, and there’s also just a ton of bizarre choices that no human would ever make.

CC (the desktop version) has a built-in terminal. It’s great idea when working with worktrees!

But the terminal is _in the sidebar_. Not as a panel that pops up from the bottom like in… every IDE ever that has this feature, but in the sidebar.

You can drag it to the bottom using tiny drag targets if you want, but if course this only persists for a duration of a single conversation.

And there’s a built-in keyboard shortcut to toggle it being shown/hidden. Again, great idea!

But using this resets the panel to its original position, again, making it appear in the sidebar.

Bonus points: when I tried to submit this via the GUI version of /feedback, it told me that it was disabled by workspace policy _after_ I filled out the form and hit submit. Brother, just hide the button that makes the form appear in the first place!

Users of Claude aren't customers, they are the product (a living training set data generators). The customers are governments and megacorpos.

He also edits bug titles to reduce the appearance of the severity while not participating in the discussion to explain why.

https://news.ycombinator.com/item?id=48948656

Well maybe stop posting then and leave it to people who are not often wrong.

Alternatively, things that are not insightful can feel insightful to some people, because they triggered some different, tangentially related thoughts than what was being communicated — i.e., the reader substituted their own insight for the author's.

Or because the author has enough authority that they are granted a presumption of insightfulness by default, even (or perhaps especially) when the concrete insight that's allegedly being communicated remains unclear.

For myself, it was useful to write down the general approach I took when solving problems. But it is useful because it was learning about myself, not because it is the same approach as the author here, and not because that is some magical best approach.

I experienced maybe a minute of being "whelmed" or +1 out of 10 over baseline because I liked reading someone else that uses this approach. For someone who thinks nothing like me, I would imagine it feeling very similar to "draw the rest of the owl."

I don't think everyone needs to think the same way. And if we did want everyone to think a certain way, well, the author's style would not convince many.

Well, sounds like problems and products are largely solved.

60% of the time, the framework works, every time.

Boris's checklist is just a slightly modified version of your classic mathematics or engineering problem solving steps.

1. Write down your problem statement.

2. State your knowns, unknowns, and assumptions.

3. Solve.

(Step 2 is also further enhanced by performing first principles reasoning, collecting data for evidence, and using reasonable estimates where data is absent.)

I think Boris's list is pretty solid, but I personally would unmix the problem solving methodology from the planning/goal setting SMART principles as two separate things. One addresses problem solving, while the other addresses human cognitive shortcomings for getting things done.

What LinkedIn post did this blow in from?

Just another instance of him being wrong, i guess. (Which he absolutely, most definitively loves!)

Bayes spotted in the wild.

Title is click-bait with poor framing (i.e. if you are often wrong, then sometimes, you will be right).

Finishing your goals does not "make you right". Life is not a binary where you are either wrong, or right. Thinking that you ever become "right" or that you ever achieve 100% confidence that you have arrived at a "solution" is arrogance of the highest order.

Life is about getting better. Every person, every product, starts at a beginning. A beginning is not "wrong", it is early. We try, individually and collectively, to improve ourselves and that which we are responsible for. The decision to ship is not whether we have made something "right" but about whether we have made it better. We ship, knowing we will ship another improvement after this one.

2. Gather missing information... 6. Achieve the goal

Sometimes in life, you need to ship first in order to gather missing information later. You cannot do that if everything has to be "right" before you ship it.

I love being wrong

This is not the essay of someone who loves being wrong. This is the essay of someone who loves becoming right. But the deeper truth is that you will always be "wrong" - unfinished, lacking knowledge, under-developed, incomplete. Do not love being wrong - love improvement.

yuck

Aka. business-as-usual being human.

Imagine it were so simple that we had not figured out 1-6 before in all of our research and management principles over the centuries?

Like as though it needs to be stated?

I mean ...

There's a very weird thing they like to do in Silicon Valley where they re-invent everything 'in other words' - this time, no fancy words.

Also, I would say he missed the 'iteration and experimentation part'.

If $400K/yer people need this level of guidance, something is wrong.

This whole things feels kind of wrong.

Imagine it were just some random Engineer, what would we think?

Imagine if a non-tech person wrote this.

"Boy, Boris, you're getting ripped on this."

I think Boris is a really smart, competent guy. He doesn't deserve the hate. That being said, he was just the person in the right place at the right time to have been empowered to vibe-code Claude Code into existence, with the momentum of unlimited tokens for the strongest agentic coding model behind him. Nothing about CC was revolutionary or insightful really, everyone was building harnesses at that time, and TBH Anthropic was a bit behind the curve in that regard. He's not some kind of "wizard" in the way that public figures in programming of the past were, and I think people are putting that on him, leading to a bit of ego inflation here.

I think if people are always told that they are geniuses, they stop being able to discern good ideas from bad ones. Then they end up writing things like this, thinking they're incredibly gracious for publicly admitting they can be wrong, and missing how the whole message comes across.

https://tiliosophrang.com/

Replace "goal" with "solution" and it makes sense. Otherwise (trite) you might solve the wrong problem.

Somehow the most relevant comment on the thread is the most downvoted.

I guess lots of people are often wrong.

I absolutely love it, and this correlates perfectly with Polya's math problem solving [1] combined with Fail Fast [2] .

[1] https://en.wikipedia.org/wiki/How_to_Solve_It

[2] https://en.wikipedia.org/wiki/Fail_fast_(business)

It’s kind of like catnip. But it’s ok, chances are that a lot of people keep asking you how you achieve success when you get to that point. You don’t really know either, but you have to write down something.

1. Do things well

2. Reflect on doing things well

3. Humbleness about the process (or other meta)

I agree. There's definitely value in it.

But I think you put it well that the problem is making it all accompanying. e.g.

Something that people learn quickly when they work with me is that my approach to pretty much every problem is:

The overall sentiment is good, positive and actionable (think, do informed things intentionally, understand things well) but I feel like the tone tries to make it all accompanying and somewhat unquestionable, which is confusing for an article titled "I am often wrong" that ends with "I am open to changing it".

They beat a lack of them, for me.

I generally agree, but I feel like there's a midground where we acknowledge positive, productive motivation, whilst also acknowledging that it is not how normal humans go around talking about their normal day to day activities. I feel I only see this stuff in environments where people are expected to be pushed to the point of being uncomfortable, and to be okay with it. There's a time and a place for that. I think it's not always sustainable, but that's not always understood/believed by younger engineers/younger me (and younger you?)

I think without that nuance, things like this will always be criticised/torn apart by people not currently in that kinda zone.

I think trying to complicate or make this lesson “all accompanying” to make it more accurate to the real world would make it lose something in the process.

Yeah, it would lose any credibility it had as you realize that there’s nothing new there.

nice

I did too

Fundamentally they just want the best effort>output ratio. You get information about this during exploration (hence "bias to action"), but you can also get information from taking a moment to step back. It's almost as if there is no catch-all rule for problem solving, which is why these posts have limited utility in isolation (but it's nice to be well-read in the area).

Go To Market/Project Management?

Yes, I think this is an anti-pattern is similar to the one I often see, basically getting the order wrong like this:

1. Define the problem.

2. Gather information about the problem.

This seems reasonable. "We need to know what we're trying to solve, not boil the ocean."

But it is really common that the information tells us that the problem definition is slightly or really wrong. Hence the importance of gather information, then define the problem... and iterate.

"First define the problem" also feels reasonable because picking the right problem requires a lot of context and experience. Some would add "taste." So in group discussions, people often suggest bad problem definitions. Others then want to get focus and traction. That impatience often results in committing too early to the problem definition.

you can only admit to being wrong if you are unfirable up in the hierarchy.

rest of us get fired if we ever admit at work that we were 'often' wrong.

I like Boris's list, if only because it's obvious. Anyone responsible for solving a problem goes through these steps, either pro-actively or re-actively.

Organizations usually suck at this part. Being time & resource constrained, the focus on anything but actual problem solving is just staggering to me. I haven't worked at every place, so your mileage may vary.

This misses the problem that your problem might not even be a problem in the first place and you shouldn't even be working on that in the first place. I'd recommend looking into Elon Musk's ethos which first focuses on finding what is actually needed and what actually needs to be done before going in and solving problems.

I'm not sure how this relates to "building a product in the age of AI" or being wrong at all, this is just a list of steps that an elementary school student would be taught when learning how to approach any reasonably complex problem.

yep, my first thought is that if THIS is what qualifies as a thought worth writing down from someone in a very prestigious position, we are well and truly fucked.