[HN Gopher] Feedback doesn't scale
___________________________________________________________________
Feedback doesn't scale
Author : ohjeez
Score : 77 points
Date : 2025-11-26 15:40 UTC (1 days ago)
(HTM) web link (another.rodeo)
(TXT) w3m dump (another.rodeo)
| kiddz wrote:
| just sent you a note Carter . . . this is something close to my
| heart :-)
| kdazzle wrote:
| I dont think the solution to not knowing people in your company
| is to create bureaucracy. Ie - only hanging with 10 executives
| and a focus group. Get out there and talk to people for a few
| minutes - at the office or wherever.
| jameskilton wrote:
| There's a lot of research on this, particularly from Robin
| Dunbar, who gave us "Dunbar's Number"
| https://en.wikipedia.org/wiki/Dunbar%27s_number
| ItsHarper wrote:
| This approach can't inform you that someone in the feedback chain
| is causing a problem.
| munk-a wrote:
| Yup - they touch on proxy relationships where you have a few
| trusted reporters to break the crowd into cohorts that you can
| mentally simplify but whenever you do this you need to accept
| that it won't be complete. You should expect and make room for
| occasional noise from the fifty people behind your one trusted
| reporter because the problem could always lie with the reporter
| themselves.
| xpe wrote:
| > Without an existing relationship, it feels like an attack, and
| your natural human response is to dismiss or deflect the attack.
| Or worse, to get defensive. Attacks trigger our most primal
| instincts: fight or flight.
|
| It is really important to recognize that it is the _perception_
| of an attack that triggers certain responses. For a counter
| example, watch how puppies play. It can very rough at some level
| but at another the intent is clearly benign.
|
| There are ways to shape and modify perceptions! Culture. Norms.
| Timing. Technology. Inclusion and exclusion criteria. Information
| architecture.
|
| Never assume that the technology or protocols you use have been
| designed for your core values. Often you have to redesign it for
| your purposes. Please do.
|
| Feedback *can* scale if one carefully defines protocols to suit
| particular goals. We are not helpless even if it seems we are
| hapless. Leaders and designers (often social scientists) must
| step up and show better ways.
|
| Computer scientists and software engineers must show curiosity
| and intellectual humility here. Better to draw broadly from other
| fields: social work, negotiation, psychology, anthropology,
| public policy, and more.
| xpe wrote:
| > Feedback doesn't scale because relationships don't scale.
|
| I would not say it this way; it is too simplistic. In fact, I
| generally caution against the dominant metaphor here of comparing
| feedback to scaling. It falls apart quickly.
|
| Here's a counter point. In many scenarios and settings,
| relationships provide transitive benefits. For example, if a
| leader builds trusted relationships with other leaders, a
| significant amount of trust can flow through that relationship.
|
| To build a better understanding, I suggest building diverse
| models. Try to answer the question: What kind of qualities do
| relationships confer and why?
|
| There's also a generational aspect here. I started my career in
| the 2000 tech boom and bust. I've seen a lot of up-and-down
| cycles in the industry. I've seen lots of management styles and
| organizational cultures. People that had formative years during
| peak social media and/or COVID often have a different kind of
| socialization and this affects their default expectations. I
| won't attach normative judgments without research, but there are
| significant differences.
|
| When I think of the most impressive collaborations I've
| participated in with amazing results, relatively few of them
| involve tech organizations.
|
| Building a scalable culture over various company sizes feels hard
| in the sense that generalizing prescriptive advice is tricky. A
| two person start up is cake because you only have to manage one
| internal relationship (a pair). People know great culture when
| they see it, but that is nothing like growing it.
| ChrisMarshallNY wrote:
| _> set the expectation that they have strong relationships with
| their own teams_
|
| Good luck with that.
|
| In most cronytocracies (typical, at the top levels of most
| companies), you get who you get. They may be really good
| engineers and "first line" managers, but suck at anything else.
|
| A big problem is that companies don't have career tracks that
| match people's skills. The Peter Principle[0] applies.
|
| Bad managers hire and promote other bad managers. Highly skilled
| engineers can often be terrible managers, but want to be
| managers, because that is the position they equate with
| "success," at an organization.
|
| A Principal Engineer should be just as valued and well-treated as
| a CTO. Most companies fail to do this, so everyone wants to be
| the CTO. Establish a career track, where technical people aspire
| to technical positions.
|
| And hire good managers; not ones that don't make the CEO
| uncomfortable.
|
| [0] https://en.wikipedia.org/wiki/Peter_principle
| mannanj wrote:
| Just experienced something similar working-at-definitely-not-
| capital-one as a principal engineer. My manager was horrible,
| and replaced by another bad manager. He incentivized bad
| behavior on my team and promoted inexperienced engineers, and
| group think, pushed me out for questioning the status quo.
| Swizec wrote:
| > A Principal Engineer should be just as valued and well-
| treated as a CTO. Most companies fail to do this, so everyone
| wants to be the CTO. Establish a career track, where technical
| people aspire to technical positions.
|
| I spent my whole career avoiding engineering management and
| trying to grow in the pure technical leadership direction. One
| day I realized that for every staff engineer there are 10
| managers, for every principal there are 5 senior managers, etc.
|
| Turns out management is not so bad and companies seem to
| appreciate that kind of help a lot more
|
| edit: also as a manager you get to work on all those pesky
| "It's a people problem, actually" parts of engineering which is
| pretty fun. Every time in technical leadership where it felt
| like "Well we've got the plan now we just gotta incentivize
| doing the plan" you're the one doing the incentivizing yay!
| ChrisMarshallNY wrote:
| I was a manager, much of my career.
|
| I _hated_ it, but was actually pretty good at it (I worked
| for a company that didn 't suffer slackers, and they kept me
| for almost 27 years). I mainly kept it, because I couldn't
| trust anyone else to do the job correctly.
|
| But my heart has always been in the tech, and I did side
| projects, that whole time. Since leaving, I ran screaming
| back to being a technical implementation person, and am
| almost deliriously happy.
|
| A _good_ manager is actually fairly hard to find. It 's been
| my experience that a majority of highly-talented developers,
| don't make good managers.
| ramon156 wrote:
| First paragraph already assumes a lot. We're a team of 5, but no,
| I cannot tell anyone my concerns or problems.
|
| I've read somewhere that company politics is necessary. Whether
| that's true, I'll probably never know.
| kylec wrote:
| When I worked at Netflix many years ago, they loved to boast
| about how they didn't have any "processes". My experience was
| that process ALWAYS exists, but at Netflix you just had to
| figure it out and hopefully not step on the wrong toes along
| the way.
| crabmusket wrote:
| Ah, the tyranny of structurelessness.
| noitpmeder wrote:
| What do you feel you cannot share concerns with your peers?
| niccl wrote:
| Not the original poster but: * that the
| interaction with a peer _is_ the problem. I know we should
| all be grown up and able to talk about these things in a
| mature and effective way, but I can't cope with conflict in
| any shape or form, so if someone says Boo to me I cave in
| which doesn't get me any further * because peers
| aren't the people that need to hear some of the things I've
| got to say, it's layers above me that need to hear it
| motoxpro wrote:
| This is a great example of why managers have to exist.
| conartist6 wrote:
| Assuming the feedback you need will just come to you might not
| scale.
|
| Going and seeking out the feedback you want does not stop
| scaling.
| Logingarrett wrote:
| I like the building relationships concept. Ideally, each person
| in your 20 person group is in a different one of the 20 total
| teams. The organization will never be perfect but I think it
| could work.
| schappim wrote:
| Feedback does scale if you're willing to adjust the loss
| function.
|
| I like the Jason Fried-ism of: If something really matters,
| you'll hear it again. If you have to write it down to remember
| it, it's probably not important.
___________________________________________________________________
(page generated 2025-11-27 23:00 UTC)