Hacker News Reader

Comment by ericb | Hacker News Reader

> The first time someone doesn’t meet an agreement, you point it out to them immediately. If they apologize, you respond that apologies are not needed, and all that is required is that they only make agreements that they can commit to and that they meet all the agreements they make. If the person continues to fail at these, there is only one consequence that makes sense: they can no longer be part of the company.”

This reads like a toxic culture playbook.

Managers can commit to nothing, or commit to things and fail when there are inevitably things they can't control and face "consequences."

A strange game. The only winning move is not to play.

View on HN

Right? And why point it out immediately the first time? Everyone messes up occasionally. No need to be habitually breathing down their neck. Rebuking an apology just makes you sound like an asshole.

This works as intended to alienate people who can’t keep the commitments they make. Both by actively eliminating them and passively making it a painful place for them to work.

The people who can keep commitments they make would enjoy working there.

I’m sure once they’ve developed a track record of keeping the commitments they make, it won’t be as draconian as it seems.

However this disincentivizes the often productive approach of “throwing your hat over the fence” so to speak and committing to something you may not already know is achievable.

Perhaps clearbit’s business model doesn’t hinge on their employees driving innovation and they need more predictable results at a reliable cadence.

This approach doesn’t work for everyone or every company. This seems to be by design.

Only management sufficiently divorced from reality can forget that "reality has a surprising amount of detail"

https://www.mckinsey.com/business-functions/mckinsey-digital...

> suggests that half of all large IT projects—defined as those with initial price tags exceeding $15 million—massively blow their budgets. On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. Software projects run the highest risk of cost and schedule overruns.

So, either this clearbit management magic makes all the normal scaling and estimation problems go away magically, or it is a really toxic management approach.

If you’re not sure you can deliver something, don’t commit to it. Instead, provide confidence levels, increase confidence by doing the riskiest bits earlier, and give frequent status updates.

> Instead, provide confidence levels, increase confidence by doing the riskiest bits earlier, and give frequent status updates.

Right--you're trying to choose the winning move: not to play. That's not really an option.

Effective management - both by the manager and the managed - is about avoiding such zero sum games. Look for the win-win and do your best to deliver it.

This is fine advice, but the topic is the "manager's handbook" not other, better, management practices, so the advice is off-topic.

Did you read the section in question?

Advice about avoiding zero sum games isn't relevant to a discussion of a specific zero sum game prescribed by the manual we're discussing.

I agree rebuking an apology is weird.

I do think it's good to point it out right away. How you do so depends on whether it mattered or not.

If it mattered: I noticed you weren't able to get X done as planned. Marketing will need to postpone campaign Y which will affect our numbers for the quarter. Can you give me a heads up early next time?

If it didn't: I noticed you weren't able to get X done as planned. It's not a big deal, but were there any blockers I can help clear for you? I want you to feel good about being able to deliver on your promises.

> If they apologize, you respond that apologies are not needed, and all that is required is that they only make agreements that they can commit to and that they meet all the agreements they make. If the person continues to fail at these, there is only one consequence that makes sense: they can no longer be part of the company.”

Ugh. "Your apology is irrelevant. Just never make this mistake or we will fire you."

Strongly dislike this quietly, creepily hostile communication style.

I think it’s poorly phrased and overly specific in how the conversation should go. The mistake of the individual is committing to something that perhaps wasn’t in their gift to deliver, and then failing to update when they knew they weren’t going to deliver it.

> all that is required is that they only make agreements that they can commit to and that they meet all the agreements they make.

An when you do that, the toxic manager responds with "Is that all you can do?"

Yeah, this is the equivalent of "people should be allowed to agree to any contract, and that contract should be strictly enforced." It completely ignores the very existence of power dynamics.

This stood out to me as well. In principle, the three strikes rule is good theoretically. In practice, it is harder than most management gurus realize. The issue is that most managers know less than the people they direct. So when an employee says this isn't technically feasible or that they don't have the knowledge or skills to implement said request. The manager doesn't have any rational basis to believe or not believe their employee. It's all based on past creditability.

I would argue most employees want to do a good job. The problem is similar to the "Peter Principle." In many cases, clueless managers demand their employees to sculpt the next Pieta or paint the next Mona Lisa with sticks and crayons and no prior training. When the employees push back against hard estimates, the clueless managers double down and say they are insubordinate. I am including Product Owners and Scrum Masters in clueless managers category. In many cases, they took on these titles but have not changed their behavior according to the Agile Manifesto. They see themselves as the order givers and the developers as the order takers.

The only people problem here is the management idea that managers/product owners/scrum masters don't need to know anything about the technology they are implementing.

This seems to encourage the Scotty approach.

Reply on news.ycombinator.com