4 ms·

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

by infamia 14d ago

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

goostavos 14d ago
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.
- kevinkoning 14d ago
  I was literally writing almost this exact post but decided to reload the page first.
- dyauspitr 14d ago
  Developers get triggered about managers breathing down their neck when they read things like this that’s why you get such strong reactions.
- thunderfork 14d ago
  I disagree, on the principle of "slow is smooth, smooth is fast"
  - TeMPOraL 14d ago
    This principle is basically a movie quote, though.
    - magicalist 14d ago
      No it's not, though?
  - whateveracct 14d ago
    and similarly, the need for slack in software teams
- phoghed 14d ago
  How often do people that make this kind of assertion end up themselves being the ones that are miserable to be around I wonder
  - cindyllm 14d ago
    [dead]
- infamia 14d ago
  > 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.
- saghm 14d ago
  If someone literally publishes on the internet that they require their employees to act like every problem is urgent, it's not clear why you think we shouldn't take them at their word. It's a pretty common thing for bad managers to expect people to work full-tilt 100% of the time rather than understanding that tends to burn poorly out. I'm honestly not sure how someone could spend a decent amount of time in this industry and not be able to recognize that pattern and have thoughts about how to avoid it unless they just don't really care about it much, so while you're entitled to disagree, it's hard not to get the impression that being so affronted by the parent comment pointing out that the blog post doesn't seem to address the very real pattern of phrases like the article uses being euphemisms for pretty horrible work cultures that you just also don't particularly care about it. Personally, I've seen far too many talented people in tech be worked too hard for too long by management that either is too clueless or too uncaring to the point where it can take years for their health and happiness to recover not to find it extremely alarming when someone says stuff like "everything is urgent". The likelihood that they mean pretty much exactly what they say rather than mean something more nuanced is high enough that the fact that don't seem concerned about the implication says more than enough.
  - tayo42 14d ago
    It's not saying treat every problem as urgent, it's saying go through 5 steps that are defing the problem correctly then treat it urgently.
    - saghm 13d ago
      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.
  - fnordpiglet 13d ago
    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.
- InsideOutSanta 13d ago
  > 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.
bmitc 14d ago
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.
- bjustin 14d ago
  > 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.
  - bmitc 14d ago
    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.
- jakzurr 13d ago
  I'm still thinking about your first para. But in the second para, did you actually mean he'll be cloned?
  - 13d ago
ccapitalK 14d ago
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.
kozikow 13d ago
> 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

by infamia 14d ago

goostavos 14d ago

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.

kevinkoning 14d ago
I was literally writing almost this exact post but decided to reload the page first.
dyauspitr 14d ago
Developers get triggered about managers breathing down their neck when they read things like this that’s why you get such strong reactions.
thunderfork 14d ago
I disagree, on the principle of "slow is smooth, smooth is fast"
- TeMPOraL 14d ago
  This principle is basically a movie quote, though.
  - magicalist 14d ago
    No it's not, though?
- whateveracct 14d ago
  and similarly, the need for slack in software teams
phoghed 14d ago
How often do people that make this kind of assertion end up themselves being the ones that are miserable to be around I wonder
- cindyllm 14d ago
  [dead]
infamia 14d ago
> 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.
saghm 14d ago
If someone literally publishes on the internet that they require their employees to act like every problem is urgent, it's not clear why you think we shouldn't take them at their word. It's a pretty common thing for bad managers to expect people to work full-tilt 100% of the time rather than understanding that tends to burn poorly out. I'm honestly not sure how someone could spend a decent amount of time in this industry and not be able to recognize that pattern and have thoughts about how to avoid it unless they just don't really care about it much, so while you're entitled to disagree, it's hard not to get the impression that being so affronted by the parent comment pointing out that the blog post doesn't seem to address the very real pattern of phrases like the article uses being euphemisms for pretty horrible work cultures that you just also don't particularly care about it. Personally, I've seen far too many talented people in tech be worked too hard for too long by management that either is too clueless or too uncaring to the point where it can take years for their health and happiness to recover not to find it extremely alarming when someone says stuff like "everything is urgent". The likelihood that they mean pretty much exactly what they say rather than mean something more nuanced is high enough that the fact that don't seem concerned about the implication says more than enough.
- tayo42 14d ago
  It's not saying treat every problem as urgent, it's saying go through 5 steps that are defing the problem correctly then treat it urgently.
  - saghm 13d ago
    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.
- fnordpiglet 13d ago
  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.
InsideOutSanta 13d ago
> 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.

bmitc 14d ago

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.

bjustin 14d ago
> 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.
- bmitc 14d ago
  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.
jakzurr 13d ago
I'm still thinking about your first para. But in the second para, did you actually mean he'll be cloned?
- 13d ago

ccapitalK 14d ago

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.

kozikow 13d ago

> 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