Live data from Hacker News

What you've got is in fact a people problem

blog.glyph.im

101–110 of 131 posts

Re: What you've got is in fact a people problem

#101
>So the intended audience for this piece is potential clients, leaders of teams (or organizations, or companies) who have a general technology problem and are wondering if they need a consultant with my skill-set to help them fix it. Before you decide that your issue is the need to implement a complex distributed system consensus algorithm, check if that is really what’s at issue.

At least 90% of the time, these leaders already know that it's a people problem. Because it's always a people problem. But presumably this guy has a good reputation which means he knows how to solve people problems. And companies are willing to pay a whole lot more than a few hundred dollars to have him be the one asking "what is fucked up about this place" than a senior manager.

I'm guessing people are a lot more honest with a consultant than they would be with the guy signing their paychecks. Does the IC3 get a raise or bonus for his keen strategic insight? No, best case scenario he keeps his job. Worst case, he doesn't.

>If you have these conversations directly, you can get something from it that no consultant can offer you: credibility. If you can actively listen, the conversation alone can improve morale. People like having their concerns heard. If, better still, you manage to make meaningful changes to address the concerns you’ve heard about, you can inspire true respect.

This goes the other way too. If the manager can't address those concerns, he loses a lot of respect. The consultant has a great excuse for failure here, and even if he didn't, he'll be gone soon enough. So it's less risky to have the consultant do this, and management likes low-risk options.

Re: What you've got is in fact a people problem

#102
post #65
post #14

What is fascinating to me about technical people is the particular subculture that sincerely believes that technology will solve the people problem. I recently got into a long thread argument with someone on HN about this. The person was adamant that people problems can NOW finally be solved by designing technology to be able to handle adversarial and incompetent actors. But the problems that such software tries to s…

I was watching some interview long ago when the guest hit it square on the head. My guess is that it was Joel Spolsky, but only because no other names come to mind as being plausible. Essentially the rant goes: So all of these people who were not particularly good at people skills in high school go into a career where they think people skills won't matter as much, and check out for 4 years while their fellow classmat…

Tech is still a pretty good option though. Having poor people skills but good tech skills means being a not-too-senior IC forever, a job with decent pay and hours relative to other career options.

Re: What you've got is in fact a people problem

#103
post #74

Earlier quoted context omitted.

I am familiar with a particular small business. They have this loop: 1. Product and Engineering cooperatively develop a project, scope milestones, cut tickets, do agile, eng writes the code and iteratively works with product to incorporate feedback and it's a grand ole time 2. They get about 80% done with implementation (so they're about 90% if the way through the entire project, impl is usually about half the time)…

This is probably most 50-200 people startups.

That's what happens when the owner is alienated from the work and doesn't have immediate goals.

When he is alienated from the work and has immediate goals, the failure is quicker and more spectacular.

Re: What you've got is in fact a people problem

#104
post #77
post #67

Earlier quoted context omitted.

The point remains that the messenger may deliver a message that invites retaliation, and even if their plan is to protect their sources, they may fail to do so. Someone who thinks they will protect you may be as big of a wildcard as someone who demonstrates clearly that they won't, because you haven't given anything really damning to the latter.

Usually, everyone knows. It's just that they need to hear it from somebody else (or will ignore it intentionally and did so up until this point).

Intentionally ignored for political reasons, so hiring the consultant allows them to address it minus the political fallout.

Re: What you've got is in fact a people problem

#105
post #8

My suspicion is that a lot of this comes down to budget pressure causing management to constantly discourage efforts by technical teams to invest time in the quality of their systems rather than push out more features. Then the same problems start popping up and the manager loses faith in their team. The times they said "no" to infrastructure development and working down technical debt may not even enter their mind.…

> Then they blame the staff for their mistake.

That is the behavior of a pathological leader in a pathological organization. It is all too common.

Re: What you've got is in fact a people problem

#106
post #26

Earlier quoted context omitted.

> Corporate "Safe spaces" are not real. Any manager is a representative of the company 24/7 and everything is on the record I have had a lot of success with knowing this, saying “Great! Let’s go” and loudly complaining about things that are fucked up to anyone who will listen. This has opened a lot of doors and gotten me into a lot of meetings that I otherwise wouldn’t have access to. Sometimes it has enabled me to c…

> Yes it takes years of building trust and a track record of successes before you can do this. Worth the investment. I built that record. The first time I gave the candid feedback that a project manager requested in an open meeting, I was off the project the next day.

> in an open meeting

Rule #0 about working with humans: You always let people save face. The improvement has to look like it was their idea, even if you planted the seed.

Re: What you've got is in fact a people problem

#107
post #87

Earlier quoted context omitted.

I miss Gerry Weinberg. Used to get lunch with him regularly He credits a man named Sherbie for the three rules. That man was my grandfather. The best advice Gerry gave me was when I was in a tough spot in college. “Expectations are fickle things that we work ourselves up over. Reevaluate them regularly, they have expiration dates long before they begin to smell funny.”

That's a long way of saying what I often tell people. "Disappointment is when expectations don't match reality" Meaning, that depending on the situation simply reevaluating your expectations can lead to satisfaction.

Reassessing expectations means, I would say in the vast majority of cases, lowering them, not raising them. I would advise, as always depending on the person and the situation, to make peace with disappointment and to have higher expectations, especially of oneself, not of others, that a reasonable person would have.

Re: What you've got is in fact a people problem

#108
post #8

My suspicion is that a lot of this comes down to budget pressure causing management to constantly discourage efforts by technical teams to invest time in the quality of their systems rather than push out more features. Then the same problems start popping up and the manager loses faith in their team. The times they said "no" to infrastructure development and working down technical debt may not even enter their mind.…

>> a lot of this comes down to budget pressure causing management to constantly discourage efforts by technical teams to invest time in the quality of their systems Anecdata follows but I’m certain this has been getting better in recent years. It’s more common today for management to be swayed by data - my recollections of the 2000s were interactions more along the lines of “I’ve been doing this for 20 years son, wha…

> E.g. if you rock up with a download of CI job runtimes and a couple of off the cuff quotes from team members about what they do when waiting for CI builds (I.e. not much of value), I’d expect you to pretty easily succeed in establish a case for investing in speeding up that feedback loop and the outcome / measured results chart of that work would likely make its way through at least a couple of senior management slide decks over the next few weeks.

No you will be waved away like always, they don't care. Features features features, nothing else matters.

Re: What you've got is in fact a people problem

#109

Earlier quoted context omitted.

>> a lot of this comes down to budget pressure causing management to constantly discourage efforts by technical teams to invest time in the quality of their systems Anecdata follows but I’m certain this has been getting better in recent years. It’s more common today for management to be swayed by data - my recollections of the 2000s were interactions more along the lines of “I’ve been doing this for 20 years son, wha…

> E.g. if you rock up with a download of CI job runtimes and a couple of off the cuff quotes from team members about what they do when waiting for CI builds (I.e. not much of value), I’d expect you to pretty easily succeed in establish a case for investing in speeding up that feedback loop and the outcome / measured results chart of that work would likely make its way through at least a couple of senior management sl…

If your management is waving off the waste of something so immediately convertible into dollars as their (probably) highly-paid engineers' time, then they're idiots.

Usually the hard part is collecting the numbers and defending their validity.

Re: What you've got is in fact a people problem

#110
post #55

Earlier quoted context omitted.

The consultant is being paid by management. S/he is beholden to them. If anything can be traced back to a group or individual, it will be, and it won't be pleasant for anyone who believed the request for honest feedback.

> The consultant is being paid by management. S/he is beholden to them. Quite the opposite. One of the reasons people go into consulting (and I don't mean working for a consulting company), is precisely because they're not beholden to them. They have much more freedom to set the terms than employees do. If a company wants them to reveal the individual, they'll be happy to give them the middle finger and let them know…

I can confirm that. I've had more than one opportunity to tell some C-level manager that asking me who said what was making them part of the problem, not the solution. It is quite an effective way to initiate reflection (whatever you think, most managers are not sociopathic morons, they just have different incentives than you).
Post reply on HN