Reminds me of an anecdote about Bell Labs. Someone calculated who the most productive employees were (based on things like patents received), and found that many of them would eat lunch with the same person. That person wasn't individually very productive, but he would always ask thoughtful, compelling questions that in turn made his coworkers measurably more productive.
It might be from the great book The Idea Factory by Jon Gertner (p 135).
The most impressive thing about this story is that they figured out the answer. They did the research, and nailed down that it was Nyquist who was was the productivity booster. It’s the exact opposite of the OP’s story, where management tried to fire the Nyquist-equivalent.
They found an answer that felt right to them. The reseachers weren't blinded to the context they were working in, and their hypothesis is essentially unfalsifiable so I would take it with a grain of salt.
Honestly, I'm kind of skeptical of the answer. I'm not saying that talking with Nyquist wouldn't be useful, probably it was, but what's stopping a dozen other things at least that useful from being part of the answer?
> I'm not saying that talking with Nyquist wouldn't be useful
No, you probably shouldn't be saying that:
https://en.wikipedia.org/wiki/Harry_Nyquist
https://en.wikipedia.org/wiki/Nyquist_frequency
> but what's stopping a dozen other things at least that useful from being part of the answer?
Because someone needs to act, and that's exactly what Nyquist did, in a very unobtrusive and non-confrontational manner.
Posting his achievements does nothing to prove speaking with him during lunch was useful in this context
> Because someone needs to act, and that's exactly what Nyquist did, in a very unobtrusive and non-confrontational manner
Seems like your headcanon. It reality they ate lunch together and passed ideas around.
For the record, I did recognize the name. That's why I believed talking to them was useful.
Concretely I'd suggest that Nyquist was probably most interested in lunching with other smart people who had interesting things to talk about.
I.e. there's no check or control on their output without lunch or breakfast with him, maybe it'd have been little different.
All they figured out was that the smart people hung out together.
IMHO this is the right answer :)
It’s a lovely story but a prime candidate for “correlation !== causation”.
Yeah that's the one! Thanks for finding the reference.
You also need a fertile soil. In many many places, curiosity, exploration is passively frowned upon.
Harry Nyquist isn't exactly an unknown engineer who doesn't have his own achievements, though - not sure why people are saying he would be fired in a modern company!
In the modern company good engineers are not valued.
Engineering excellence is not a prerequisite to business success. Managers know this.
Why else many things any one of us could list from the computing business.
I agree with you 100%. Management does not have an eye for software that is easy to maintain and continue to make money on 5 or 10 years down the line. Most management is thinking short term, how do I get money in MY pocket right NOW. Who cares how the business does in the long term, they'll jump ship and move on. It is the engineering that often makes a difference for long lived companies, it's just that usually the engineers and/or management isn't around long enough to reap the rewards. I try to balance engineering with product cost (I'm lucky enough where I can see the "numbers"). I try to give more to the clients that pay more, or at least create something that I can reuse in the future, while making sure what I deliver is stable and not a big ball of spaghetti to make the next developer/engineer cry at night.
> ... 5 or 10 years down the line. Most management is thinking short term,
Woe is us. Five or ten years is not considered short term
> . I try to give more to the clients that pay more, or at least create something that I can reuse in the future, while making sure what I deliver is stable and not a big ball of spaghetti to make the next developer/engineer cry at night.
I am not sure about the "...who pay more". As I am currently woefully underpaid I am more sympathetic to that view than once I was, but, I still view myself as a professional, and I act with professional ethics.
Partly that means speaking up when I see a project going near the rocks. I do not make too much fuss, but I do say it out loud.
That has cost me plenty. Our industry is full of people who are very good at one thing or another, but do not know their limits.
Part of my "being professional" is knowing my own limits.
I am in 100% agreement and the same thinking as you are. I never take the shortcut route unless it is absolutely warranted, such as a solution I know is meant to last only a few months. I have been very loud, and have effected quite a bit of change over my years, if only in a way that allows my boss to believe that I will no longer be a part of his operation if he restricts my freedom and personal ethics. I am highly underpaid, but I make sure to take that out in personal freedoms where it is worth it to me. I no longer answer phone calls or texts after hours unless they are going to directly damage the business, and my ability to continue having a place of employment. I take regular vacations, and mental health days, sometimes just to spend time with my son (went through a divorce where I still can't tell how badly it affected my son, although luckily went through a moderator rather than the attorneys/courts to settle things).
It is important to know what you can and can't get away with, and my clients don't pay the cost of the business I'm employed by making bad decisions. Where I am able to, I strive to provide a product that is better than the average, in the hopes that I've developed a solution that can possibly benefit the company or myself in the future in regards to software quality or speed (along with stability) of deployment.
He doesn’t have his own achievements?
I have heard of the Nyquist frequency, the nyquist limit, the nyquist sampling rate and the Shannon nyquist theorem.
As far as I know no other individual has had this many “things” named after him.
The GP used a double negative.
https://en.wikipedia.org/wiki/List_of_things_named_after_Joh...
Note that the "Known for" section on his main page has 119 elements. But they're not all named after him.
Also
https://en.wikipedia.org/wiki/List_of_things_named_after_Leo...
Oh my! You buried the lede:
"In an effort to avoid naming everything after Euler, some discoveries and theorems are attributed to the first person to have proved them _after_ Euler."
Did you skip over the word "isn't"?
Reminds me of the adage of “solving the problem is the hard part, the hard part is figuring out the right problem to solve”.
I always remember as “questions are harder than answers”.
Rumour has it Nyquist was promised to be on 18 breakfasts a day to placate investors after a slow quarter.
Wiki says it is this guy: https://en.wikipedia.org/wiki/Harry_Nyquist
Woah. He has a huge list of "Known for"!
That kind of people was somehow mentioned in Peopleware. A group of people is a subtle structure, and good team spirit, good questions can improve things "invisibly".
This type of person needs to start a company, they never get paid a fair wage otherwise
True for most of the working class, whose surplus labor value is siphoned away by capital.
For all a lot of people dump on Scrum Masters and Agile Coaches . . . this is part of who the good ones are supposed to be.
Oh No!
Good people amplifiers are domain/technical experts; Scrum Masters/Agile Coaches are neither.
If anything many seem super green with 1-2 years tech experience.
The plural of "anecdote" is not "data."
I'm sure your bubble is a wonderful place for you to exist. I can't speak for anyone who has to interact with you, but inside of it, I'm sure it's great.
I could echo the same sentiment.
At this point i think it is rather well established; eg. "Taskmasters" in - https://en.wikipedia.org/wiki/Bullshit_Jobs
It's basically a trope on this site for everyone to imply that everyone who doesn't have their fingers in code 8+ hours a day has a so-called "bullshit job," as if developers don't work for businesses which have to earn money, so forgive my skepticism.
And yes . . . I do code.
You have missed the point.
It has nothing to do with coding but everything to do with adding tangible value towards achieving an Objective Goal (Business/Technology/whatever). Hence the Problem Domain and technologies used in the Solution Domain are what matter and everything else is ancillary. The Processes/Methodologies used are only useful in as much as they help us understand the problem domain better and map it to a specific solution. Thus the application of the former is informed by knowledge of the latter and cannot exist by itself. Hence the reason we have so many types/variations of Processes/Methodologies; there are some common principles but will always need to be adapted/customized to the problem and tools at hand.
This is what is the problem with modern-day Management/Leadership and eloquently pointed out by David Graeber(Bullshit Jobs - https://en.wikipedia.org/wiki/Bullshit_Jobs) and Jeffrey Pfeffer(Leadership BS - https://jeffreypfeffer.com/books/leadership-bs-fixing-workpl...).
I highly recommend reading this speech by David Packard (one of the founders of Silicon Valley via HP) to new Managers given in 1960 and note how relevant it is for all companies today - https://gizmodo.com/the-hp-way-how-bill-hewlett-and-i-built-...
Relevant Excerpt:
Over the years we have developed the policy that it is important for the supervisor to thoroughly know and understand the work of his group. A debate on this has been carried on by management people for years. Some say you can be a good manager without having the slightest idea of what you are trying to manage, that the techniques of management are all important. There are many organizations which work that way. I don't argue that the job can't be done that way but I do argue strongly that the best job can be done when the manager or supervisor has a real and genuine understanding of his group's work. I don't see how a person can even understand what proper standards are and what performance is required unless he does understand in some detail the very specific nature of the work he is trying to supervise. We have held closely to this philosophy and we intend to continue to do so. We expect you who are supervising to learn techniques of supervision and keep up to date. I want to emphasize you can supervise best when you know a great deal about the work you are supervising and when you know the techniques of supervision as well.
There is a difference between "understanding the work" and "knowing how to do the work".
I've had multiple Producers who "understand the work" of creating mobile games as a whole and understand how the team needs to work and interact to produce a result on time.
None of them could code a mobile game to save their life.
What your example is talking is a situation where a fresh off the press MBA is shoved in to a very specific field and they start just doing pure numbers and Excel management out of a management book without knowing how that specific industry operates.
Managing a team of deep-sea welders is VERY different from managing a software team, which is again different from managing a team of people building a physical machine.
>There is a difference between "understanding the work" and "knowing how to do the work".
True. However, the relationship between them need not be a "Total Function" but definitely needs to be a "Partial Function" to a certain degree. You cannot be completely divorced from the "How" and hope to have a good "understanding" of the system.
>Managing a team of deep-sea welders is VERY different from managing a software team, which is again different from managing a team of people building a physical machine.
This is precisely the point; domain/technical knowledge is needed to effectively Manage a project. This is independent of knowledge of techniques of Management. The problem today is that entire industries have been created out of thin air which posit that the latter is sufficient if one follows a certain process/methodology which is patently absurd.
> You have missed the point.
No, I think at least in large part, you missed the point.
> It has nothing to do with coding but everything to do with adding tangible value towards achieving an Objective Goal (Business/Technology/whatever).
As I understood _Bullshit Jobs,_ "adding tangible value" to some business that doesn't actually add anything of actual (non-monetary) value to the world is bullshit. There are whole industries that make billions of dollars, but everyone who works in them is still doing a bullshit job. (I often think I do.)
You are talking about the meaningfulness/meaninglessness of the Business/Technology Objective itself. That aspect is certainly relevant and can be Bullshit (eg. companies selling Scrum master/Agile coach certifications :-) but in the context of this thread we are talking about the bullshit jobs created within an organization in the bureaucratic/administrative/managerial/leadership "roles". This is what is more insidious and needs to be rebelled against.
From https://en.wikipedia.org/wiki/Bullshit_Jobs :
... as he describes, five types of entirely pointless jobs: ... 5. Taskmasters, who create extra work for those who do not need it, e.g., middle management, leadership professionals.
In companies, he concludes that the rise of service sector jobs owes less to economic need than to "managerial feudalism", in which employers need underlings in order to feel important and maintain competitive status and power.
From https://en.wikipedia.org/wiki/Bullshit_job :
Graeber also formulated the concept of bullshitization, where previously meaningful work turns into a bullshit job through corporatization, marketization or managerialism.
Nope.
The best amplifier I've met was hired as a junior coder to my team and was paired with a couple of 10x coders on a project with a client who was "hands-on" and loved to micro-manage, having been a software developer themselves a long time ago.
The Amplifier's coding output wasn't that good, but the team as a whole was doing better than before so I investigated.
Turns out the 10x guys weren't that keen on communicating with ... well anyone outside of the team, much less with non-technical clients (or technical clients who loved micromanage). Both were your stereotypical cold pizza and warm cola coders with limited social skills. They could kinda sorta manage the meetings and emails directly from customers but didn't exactly relish it.
The junior hire was more like a 0.5x coder, but had ample social and organisation skills and worked extremely well as a liaison between the team and any external contacts they needed, taking over most "useless" meetings with the product owner and customer.
The junior coder ended up receiving some training and was "promoted" to a Scrum Master/Producer/Project Manager (the exact title escapes me) for the team. Everyone was happy and productive.
Your anecdote actually reinforces my comment. See my comment below for context - https://news.ycombinator.com/item?id=37378513
Your "Amplifier" is more like what is known as a "Field Applications Engineer" in the Embedded industry i.e. somebody with enough Domain/Technical/Marketing/Sales skills fulfilling a tangible need for the Business. They are more a "Business Process Optimizer" than a "People Amplifier"(a term i made up :-) who i define as somebody who can spark creativity/insights/viewpoints etc. which push others forward in their problem-solving endeavours. It is not merely removing hurdles/book-keeping/time management/liaisoning but an active role involving discussions/brainstorming/idea generation. This cannot be done without bringing some expertise to the table relevant to the problem at hand.
Do people honestly think this kind of thing replicates with formally scheduled Zoom 1:1s? I don’t.
I don't know about you, but I don't tend to have breakfast and lunch over Zoom.
While I did go out to lunch with coworkers more often while working in the office it was almost exclusively with direct teammates, and other groups I occasionally saw where also on the same team.
Now that I'm fully remote, I will typically do a few "hacking sessions" over Zoom every week. Its much easier and more comfortable than standing over their shoulder in tiny cubes we used to have.
That said, especially now that i am fully remote, I've been trying and mostly failing to get developers especially across teams to talk and collaborate more. But its not too suprising: I was recently in a call and I was introduced to another developer who I replied, "Yeah, I know you. I was in the cube next to you for 2 years and on your team for 6 months."
Remote creates some new challenges, but its a culture thing, not a technology thing.
FWIW, I schedule coffee with colleagues over zoom.
It's not the same as having lunch together but it is enjoyable and useful.
You know, after I wrote this I got to thinking, "Why don't I have have more social Zoom calls?"
The answer is that I never was good at social things like inviting people to coffee.
But it doesn't help that we're taught to "protect" our time and avoid unnecessary calls and meetings. Presumably so we can write more lines of code, close more tickets, or earn more points like the story and other anecdotes here.
I think I may try something new in my calendar. Worst case I'll end up sitting in front of my computer alone with a block for the next hour and nothing to do but work on all those things I need to do anyways.
My thoughts were that neither of them should have been surprised by the rating. When a rating comes in substantially different than expected, it's usually because A) They aren't talking during the week B) The manager is weak and doesn't want to issue corrections when they meet C) The employee isn't asking "How am I doing?" during their meetings D) It's being directed from upper management for obscure reasons.
That is a catalyst!