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 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.
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.
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”
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.
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)
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".
He's often wrong, don't you know.
Just not about your performance review.
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".
I also don't like that urgency is built in as the standard process either, no wonder everyone is burnt out.
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.
and the fun question of how do you find good problems is very hard to systematize!
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 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.
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.
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.
Unlike me, 56 and yet to be wrong once.
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.
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.
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.
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)
“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.