Hacker News Reader

Comment by IronKettle | Hacker News Reader

This is totally an incomplete thought, and I'm not trying to be down on this author in particular:

It's interesting to see a lot of management thoughts and colloquialisms slowly creep into the "other side" of software development (i.e. the actual developers) and become fairly well-tolerated.

We still make fun of phrases like "paradigm" or "synergy", but we're all mostly on-board with phrases like "own <x>" or "growth mindset". You can see the author using the word "leverage" here repeatedly in the same way that we often chide managers for using words like "synergy".

Interestingly the conversation around "effective engineers" has also shifted to really de-emphasize that technical ability - the best engineer is a good teammate, first and foremost (and I think a not-so-subtle implication also is that a good engineer is mostly extroverted as well). In the past decade or so, it seems like the "effective engineer" has become one who straddles that line between management and technical ability.

I don't really have an opinion on this yet (I think there's good and bad, as with most things), but it's just fascinating to watch.

View on HN

It's less about management and technical ability, and more about soft skills and hard skills.

A recent Washington Post article shared an analytical study from Google on what made engineers at the company successful:

"Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last. The seven top characteristics of success at Google are all soft skills: being a good coach; communicating and listening well; possessing insights into others (including others different values and points of view); having empathy toward and being supportive of one’s colleagues; being a good critical thinker and problem solver; and being able to make connections across complex ideas."

Unfortunately, almost all computer science education nowadays focuses on pure technical skills and hiring interviews at most tech companies also focus on the technical skills. The impact is that many engineers plateau in their careers because they've underinvested in (and oftentimes looked down upon) the "soft skills" that actually separate the top engineers from everyone else.

Here's the article: https://www.washingtonpost.com/news/answer-sheet/wp/2017/12/...

>Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last.

This result seems a bit unsurprising. People who work at Google would already be in the top n-th percent in terms of STEM expertise. If everyone you hire is 'above average' then being a bit better than that has marginal gains and other factors would lead to your success. I'd be curious to see how this plays out at smaller firms where they cannot afford to hire the top-end STEM expertise.

Your observation is a great one, and I'd love to see more data on this as well.

A related point, though, also rings true. Soft skills like being a good coach and effective listening are so underinvested in, that even marginal improvements in those skills lead to huge differences in success.

I see this in engineering leadership workshops that I've run with Jean Hsu and Diana Berlin, where even teaching a handful of coaching and listening skills can have a transformative impact on participants.

If you're interested in future workshops, you can sign up to hear about them here: https://effectiveengineer.typeform.com/to/cDMeZu

Do you have any ideas on how companies can better assess soft skills during interviews?

At Quip, we run one coding interview that happens on a laptop, and where your conversation and discussions with the interviewer, including how you handle suggestions and feedback, matter a huge deal.

For experienced hires, we'll do deep dives on technical projects that they've worked on. Sometimes, I'll frame these as "Suppose I'm a new member joining that team. Bring me up to speed." These interviews focus on whether the candidate can clearly articulate concepts, explain the big-picture motivations, defend decisions they've made, understand complex technical problems, and stay humble and share lessons learned.

For manager interviews, we'll also do interviews that are one-on-ones with engineers on actual issues that they're facing.

> we'll also do interviews that are one-on-ones with engineers on actual issues that they're facing.

Be careful with this approach. If you're not paying candidates for their interview time, you're not allowed to use their work. Big companies go to great lengths to demonstrate that the entire interview is for the purpose of a hiring decision and nothing more. This is to limit liability. Your approach is very dangerous for your company and if an unhired candidate's idea shows up in your product, even if you arrived at that result independent of the interview, the candidate has a strong case against you in a lawsuit.

If you're doing interviews like this, be sure you've discussed all the nuances with your company's lawyers.

Do you just want something that assesses soft skills?

Or do you also want something where all your interviewers will give the same candidate the same score, and that's robust against being gamed?

The former is easy: "Tell me about a time you helped a colleague improve their performance", "What do you think makes for a good coach?" etc etc.

The latter? I've never seen a convincing way of doing it.

I strongly agree with this analysis. It's already a population with strong STEM abilities, it should suffer from some sort of diminishing returns after an already high hiring standard on a company well-known for hiring only top students.

It's like conducting an analysis on skills of all F-1 drivers, and what differentiates champions from remaining pilots. I'd expect a lot of mindset-related and soft skills to appear as key indicators, and "driving abilities" to have a minimal gap between drivers.

This makes so much sense and frequently overlooked. I find even in other areas (such as sports), what makes someone seem really impressive generally isn't what is actually important.

A dumb example is from cycling, people frequently over-practice the ability to sprint at the end of a race but what is really important is the ability to conserve energy throughout the race... Really dumb example, but I think it is somewhat similar.

Another likely bias is that success is probably measured by peer review, and peers are more likely to overvalue soft skills.

Is there any evidence this is happening? I work at Google and as a lower level engineer more often than not wish some of the leads had better soft skills which makes me think they're not emphasized nearly enough in terms of promotion, which is at least one measure of success.

I believe promotion committees try to see measurable impact, which at least to me sounds like soft skills unfortunately don't help much..

Hopefully this will not morph into another recruiting mantra like it went with bullshit interview questions.

This would be like a study that found that height was completely uncorrelated with performance in the NBA. Doesn't mean that height is irrelevant in basketball, only that selection bias is in full effect and that we're not looking at a 'normal' population with respect to height. Same IMO with respect to google and engineering skill.

The seven top characteristics of success at Google are all soft skills: being a good coach; communicating and listening well; possessing insights into others (including others different values and points of view); having empathy toward and being supportive of one’s colleagues; being a good critical thinker and problem solver; and being able to make connections across complex ideas."

That is describing what it takes for an individual to be successful in a group of men. I think Im safe in saying this is like that since the dawn of men. Specifically here, it happens in organisations big enough so that people's actual productivity is unknown.

Innovation though generally doesn't happen in such environment.

What about this is specific to men?

I meant human.

By group of men are you using that like group of people or are you saying it's specific to males?

I meant human

> Unfortunately, almost all computer science education nowadays focuses on pure technical skills

I'm not sure I'd really call that unfortunate. CS education isn't about making you a more well-rounded person: It's about giving you a basic education in Computer Science.

Similarly I don't really lament that CS programs don't have a course in basic financial literacy, even though it would be incredibly useful.

These are really topics that should be addressed much, much earlier (empathy in particular is something we should start teaching children as young as possible) and should be mature ideas by the time people reach college-age.

> The impact is that many engineers plateau in their careers because they've underinvested in (and oftentimes looked down upon) the "soft skills" that actually separate the top engineers from everyone else.

To mirror the other comment, I hate to say it but if you're a software engineer at Google you're likely already a "top" engineer.

You're trying to explain what differentiates the top 0.1% from the top 1%, but I'm not sure it's a super useful distinction for the other 99%. For them, investment in hard skills might actually be considerably more fruitful (and land them that Google job in the first place).

Maybe not, I'll admit I could easily be wrong on that.

There's for sure a tricky balance on what fits into a CS education.

I remember when I was at MIT (oof, over a decade ago), many project-based CS courses where students were just put into teams and expected teamwork to just happen. Sometimes people got along, and the project would go fine. Other times, not so much.

I know I certainly wasn't very well-equipped to handle tension or to have hard conversations about fair distribution of work. And back them, I ended up just avoiding them. Knowing what I know now, even a single lecture on tools for more effective teams or for having hard conversations or giving feedback would have made those projects SO much more valuable in terms of being learning experiences.

Given that effectively using your CS education will involve collaborating with other people to some degree, I do believe that giving more emphasis to the non-technical skills that play a big role in your career would have a hugely positive impact.

> I know I certainly wasn't very well-equipped to handle tension or to have hard conversations about fair distribution of work.

I guess my point is more that primary school really should've prepared you for this: Group dynamics and how to handle these "group tensions" is more of a basic learning skill that we should be developing very early on.

I'm not arguing that this is a useless skill to teach, more that it's far more expensive and much less effective for MIT to be teaching you these skills and not MyTown elementary/middle/high school.

Why can't the managers with business backgrounds be the social engineers expertly manipulating the asocial software engineers? I thought that's what they were for. Distribution of labor!

I think for me it's more like:

One of the fundamental duties of a middle manager is to worry about group dynamics, team effectiveness, group communication, etc.

If the engineers are now doing all of that as well, what's middle management doing?

("Nothing, same as always" is of course the snarky answer)

> Unfortunately, almost all computer science education nowadays focuses on pure technical skills

Assuming by computer science education you mean the actual classes within that major, I don't see this as a problem. I didn't take CS classes to learn interpersonal relationship skills. Other college classes and the college experience in general does help with that though.

If talking about tech programs, I also think that isn't necessarily something they can or should focus too much on, as that's not their focus. The assumption is you have that part already figured out. If not, go through a course that focuses on that in addition, I'm sure you'll get a better education in that topic that way. It probably is appropriate for them to stress it's important though, even if they don't offer much in the way of rectifying it.

Or, spend a lot of time on self-directed self improvement in one or both those areas. The resources and programs exist for that as well.

> and hiring interviews at most tech companies also focus on the technical skills.

I agree on this. Companies should hire people that will function within their system. Hiring the smartest guy from MIT's class of 2017 sounds all well and good, but if they can't function well with your existing 100 employees and they leave after a year or two (or worse, they cause a few other people at your company to leave every year causing high turnover), the chances of them somehow making up for that are probably extremely low.

Our CS program had a "basic communication" class, where you learned to write basic reports, memos, emails, your resume, etc. The final project was investigating some piece of tech, writing a 30 page paper on it, and presenting your findings to the class. Other CS teachers were invited to drop in during the presentations too.

Supposedly they added this after receiving feedback from industry that the biggest problem was that their graduating students couldn't properly communicate.

Altogether it felt pretty appropriate, since it was still focused on CS related concepts.

This is the article that argues that for people in the top 1% of STEM expertise, STEM expertise isn't the distinguishing factor.

Frankly, it would be surprising if it was. If you've topped out that tech tree, most of your performance variance will come from other areas where there's more, uh, variance.

I can’t speak to this particular study, but as a former Google employee, I would take any of the social “research” done at Google with a massive grain of salt. Very little is peer reviewed (or even externally available) and the stuff I looked at internally is not even remotely rigorous.

Additionally, the results that make it to the media get way exaggerated compared to the actual underlying study. This is compounded by the fact that Google picks and chooses what it publicizes, so what you’re seeing has a huge PR/political filter.

The prase "success of people working at X is correlated with Y" has about the same meaning of "X recruitment process is weakest on select Y".

> Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last.

And yet it seems to me that the typical software/technical interview process emphasizes #8 more than the other seven. Maybe like the drunkard searching for lost keys under the lamp post. Quite sobering.

among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last.

I have a lot of those soft skills. But no one is going to hire me as an engineer because I don't have the coding skills.

It comes in dead last because you have to have high level coding skills to get your foot in the door. Everyone has that. Getting ahead in that crowd means having others assets on top of being a good coder.

It is a little like saying "Height doesn't matter for success as a basketball player. As long as you are at least 6'6", what matters are these other attributes." Yeah, sure, cool. It isn't a strong differentiator for the in crowd because you can't even join the crowd without it.

I agree. If everyone at some company meets some bar for expertise, then differentiation among peers comes elsewhere.

There are quite a few implicit assumptions here that make it a dubious example, though.

For example, there's an assumption that what works well at Google would work well for other tech firms. And yet Google is in the rare position of having gained so much from its early golden goose that success in terms of producing viable, valuable products and services has been almost irrelevant among most of its workforce for most of its existence.

There's also an assumption that the staff at a big, famous organisation like Google are generally better than those elsewhere, and therefore that being successful in such an organisation is something to be emulated. Working at one of the Big Five seems like a default aspiration for some parts of the tech world, and there's definitely an element of hero worship for those who have made it. I can't help wondering whether that is simply because of the amount of money they can throw at new starters in the hope that they attract some of the best people among the catch.

What I see here is that if you're in an environment where being good at walking the walk isn't always necessary, talking a good talk becomes the path to recognition and success. While this is almost certainly true, anyone who's ever observed the phenomenon of middle management could have told you that, without reference to any specific industry. What it doesn't tell us is how much being able to walk the walk matters in most other environments where it is necessary for success.

I did some reading into project Oxygen. From what I could tell it set out to find the most important qualities for managers at google, which made the results much less surprising. I would love to find more info on this either way.

Worth keeping in mind that this is true for the culture/environment within Google, not universally. Different companies have different cultures, and the above actually makes me more cynical about the culture within Google. If two people have competing ideas for a engineering solution/implementation, is the winner going to be the one with the best technical merits, or the one best at office politics? Judging from the above study, it seems like Google's culture is less meritocracy-driven and more politics-driven than people think.

This is a mindset that I encountered a lot from managers and VPs at Google. The premise is that the best way to improve one's incremental technical contribution is to improve an entire team.

If you bust your ass for a year and improve your own technical chops, you might be able to implement stuff 10% faster. Instead, you could help a team of 30 people to produce 10% more work. This is achievable from my anecdotal experience, but citation needed. At this point, you can throw your 10% incremental improvement out the window because now your incremental engineering improvement is 10% of a 30 person team, or 3 engineers. Now imagine you organized a department of 300 engineers to develop the right mix of infrastructure, forward-looking projects, and core projects such that the organization runs and grows efficiently. Now your incremental technical contribution is so much larger than the initial 10% that it's laughable.

This doesn't have to be limited to management, which is where I think the Google VP perspective falls a little flat. You can do this kind of work through pure technical contributions. I think managers write about this kind of leverage more often, but it can come from any kind of organization. A core library or tool has a massive impact, because it's reusable past the bounds of your team. Maybe you're change isn't 10% distributed across 30 people, but you could improve 3000 people by 1%.

Yeah, and I think this is where it's fair for the author to use terms like "leverage", since you're effectively multiplying force.

To be fair, though, I don't think having that team-first mentality (where you're focused on improving the team's productivity as opposed to your own) necessarily implies pervasive "management thinking" (for lack of a better phrase) or even soft skills. I imagine we can all think of teams where that isn't the case.

This Leverage concept can be applied to a family .

Instead of YOU, as head of household putting more hours to solve Home chores/issues, if you teach other 3 members of your family how to solve issues/do chores , you get 3X return .

An example is online shopping for Home: Instead of you spending time for all the research each time, teaching family members, you can achieve leverage .

> If you bust your ass for a year and improve your own technical chops, you might be able to implement stuff 10% faster. Instead, you could help a team of 30 people to produce 10% more work. This is achievable from my anecdotal experience, but citation needed.

> At this point, you can throw your 10% incremental improvement out the window because now your incremental engineering improvement is 10% of a 30 person team, or 3 engineers

I think you're being a little too pessimistic, although I do see where you're coming from. Technical jargon and vocabulary aren't created out of thin air: they are meant to efficiently and effectively convey certain facts and behaviors. Sometimes (perhaps many times?) there are co-opted and misused by certain people (many times managers, since they're further away from actual coding).

The thing about engineer being a good teammate: I don't think it is about extroversion as much as realizing that modern software systems are very non-monolithic and thus require cooperation among many different services to work effectively. This means that the days when a person could write the entire thing by himself/herself is over, and a lot more co-operation is required among engineers to design and build effective systems. That cooperation requires a certain amount of communication skills (apart from stellar technical skills), but it doesn't mean that you have to be an extrovert.

I think often lost from the whole introversion vs extroversion debate is that:

1. It's not a binary. It's a bell curve where many people fit near the middle and some are extreme outliers in either direction.

I know personally that I am an introvert, but I confuse a lot of proclaimed extroverts who mistake me for being extroverted because I have a fairly gregarious and willing to try anything once personality.

2. Introvert / extrovert really has nothing to do with communication skills except that introverts appear to be bad at verbal communication usually because that skill isn't as practiced as extroverts. But good verbal communication is totally a developable skill rather than something innate to a person.

> That cooperation requires a certain amount of communication skills (apart from stellar technical skills), but it doesn't mean that you have to be an extrovert.

Yeah, and I realize it's a spectrum and not a binary thing. My point was more:

If we use the simplistic, trendy definition of introversion/extroversion as "do you gain energy having conversations or does it require energy?" and then say that regular conversations are an extremely important part of doing modern development work, I think it's fair to say that you're implicitly selecting for extroverts.

And again, I don't really put a judgement on that. I think it's fair to say "regular conversations are required to be successful as a software developer." I'm just noting the shift (as you've also done!).

> That cooperation requires a certain amount of communication skills (apart from stellar technical skills), but it doesn't mean that you have to be an extrovert.

There are many people (including myself) who can operate quite successfully in the text-based world (Slack, email) and collaborate that way.

I think Slack (and other tools like it) helps the introvert be a more active participant or even a leader in certain technical discussions. Most especially, the ones where the servers are melting down.

That's very true! I wasn't really thinking about Slack/etc. when I made that statement. Excellent point.

This means that the days when a person could write the entire thing by himself/herself is over, and a lot more co-operation is required among engineers to design and build effective systems.

At that point, you're not really talking about being an effective engineer, though. You're only talking about being an effective engineer in a large organisation working on a large project.

I know plenty of people in the freelancing and startup world who can build and maintain very significant systems single-handedly. Take someone with the skill and experience to do that, give them a free hand in choosing whatever tools and processes work for them to get a good job done, and remove the overheads of micromanaging this and co-ordinating that. It's not unusual for that person to outperform an entire team working for a competitor under more traditional constraints, or for a small number of such people who can keep the overheads down to outperform a more traditionally organised but mediocre team an order of magnitude larger. Of course these people also need good soft skills, but those are not why they are so productive.

"Leverage" has real meaning. Another word for it that you might be more familiar with from software is "reuse".

Reuse is leverage. If a piece of software (function, class, module, service, tool, whatever) is used for 1 task, it's not leveraged. If it's used for 10 tasks, that means the creation of the reused thing had 10x leverage: working on that reused thing created 10 times more value than working on something that's only used once.

It's not quite that straightforward as everyone knows, there are costs to reuse (abstractions (both lowest common denominator and leakage), more dependencies, higher maintenance costs owing to risk of breakage of multiple clients, etc.). But the leverage is very often real.

What's your point? Synergy has real meaning as well. The problem is when concepts like leverage or synergy become goals in and of themselves. That might be something you'd expect from someone who's read a lot of management books, but you'd expect engineers to see these as means to an end.

While I don’t advocate the use of these terms in every situation, it’s hard to have all ends in mind and to carefully choose which tool should be applied to each end. That may be why these properties are used as goals. Easier to spot, easier to reason about. Basically, they are heuristics.

> You can see the author using the word "leverage" here repeatedly

Or maybe devs/engineers are just growing more eloquent than used to be? "Leverage" is truly the most intrinsic essence of everything engineering/developing. Reducing man-days, eliminating manual efforts, extracting infinitely reusable abstractions, code that emits+evals code .. I could go on and on and on --- hard to find a more sufficiently terse umbrella moniker that captures the mindset behind it all than "leverage"!

I've heard multiple similar arguments in favor of the word "synergy" or "paradigm".

Let me turn the tables: Why is "leverage" acceptable to use but "synergy" engenders scoffing?

Fashion

The terms themselves don't induce scoffing, it is the specific usage patterns over time, which then becomes associated with the term, devaluing it as a meaningful way to communicate.

Synergy was frequently used in a mindless, vague way by individuals who wished to appear in-the-know. Thus, it was devalued, as people actually in the know did not want to be mistaken for those those who didn't know how to use the term.

This dynamic usually happens with high-level abstractions that have much complexity and nuance, as it is difficult to assess if the term is being used in a meaningful way. "Paradigm" and "synergy" are good examples of such powerful yet tricky concepts prone to misuse and buzzification.

Some philosophers say that the meaning of a word is determined purely by its usage. In this view, a word like synergy loses much of its meaning, as it is commonly used in such a jumbled and unclear manner.

> Synergy was frequently used in a mindless, vague way

Again, I'm really not trying to put the author down here - but "leverage" is a term that can very easily and often is used in a mindless and vague way. Not always, of course, in the same way that "synergy" can absolutely be used properly.

Still, it would be extremely easy for me to mindlessly posit whatever I want as "high impact", or at the very least "minimal time investment". "Minimal" and "high impact" are inherently subjective phrases (minimal compared to what? high compared to what?) and without a baseline are effectively useless.

So, I guess I still don't see a huge difference between "synergy" and "leverage" in terms of vagueness. And if vagueness exists, mindless usage is pretty soon to follow.

I agree "leverage" is further down the spectrum of being prone to meaningless usage (than most words), but I don't think it is as far as "synergy".

It's a more precise concept: put x in, get more than x out. The more you get out for each input of x, the greater the leverage.

Synergy is the idea of "greater than the sum of the parts", which is a useful concept but much more nebulous, in my view.

Not that this is a particularly important debate :)

I'll take that table-turn! Well my intuition here goes like so: think back to the first moment in life you heard about a "lever" --- then "synergy". Chances are, the former was an illuminating childhood moment when simple levering was first powerfully demonstrated to you by a peer or parent, and tickled your inner engineer/fixer-upper/tinkerer. Chances are, no comparable "engineerish" moment occurred when you first encountered the latter.

Probably the wrong person to ask :). The first time I heard the word "synergy" was downloading https://symless.com/synergy , which was an incredibly useful piece of software and absolutely did tickle my inner engineer (trying to figure out how it worked).

As far as I'm aware, 'growth mindset' comes from education/psychology with Carol Dweck, not from management - did I miss something?

Not the first or the last time management has co-opted terms from academic fields :). Social psychology is especially ripe for this.

See also: "Paradigm shift" was coined by a physicist to talk about scientific revolutions, IIRC.

This frustrates me greatly. Many "engineering management" professors will show Dilbert strips and Office Space memes, then immediately fall into using the same kind of vocabulary that these works mocked.

(Recall that Initech in Office Space had "Hawaiian Shirt Fridays" - one of the core features of this manager-speak is to try to appear human and relevant as much as possible.)

I'm first in line to make fun of the title "scrum master" and other nonsense. But the things that have crept in seem to have because they work.

I'm results driven. I don't care who comes up with what or what it's named. If it works, I'm on board. If it doesn't, I'll lambast it.

>But the things that have crept in seem to have because they work.

Keep in mind that things like Agile and Scrum might have had buy-in from team members because a team member adopting it wasn't as high of a cost as the same team member leaving the job. You might be able to object, but you'll probably be overridden.

There's some amount of reprogramming that happens there to keep the team cohesive, so people might begrudgingly adopt new habits. So in those cases, "it works" is barely sneaking in because everyone was forced to make it work.

It's not as easy to prove/disprove as more objective things like program performance, size, or correctness. There's a whole lot of flavors of "it works" out there.

Many adults have an aversion to new words. Foods too! Over time, they grow accustomed.

I don't think so. Leverage has a precise concrete meaning in this article. We shouldn't avoid a descriptive accurate term just because it's for an abstract higher-order concept.

> Leverage has a precise concrete meaning in this article.

Er, not really. From the article:

> Leverage = Impact Produced / Time Invested

"Impact Produced" has a precise, concrete meaning?

Sure. For software, it might be reuse of a component. Reuse leverages existing code. This is precise, unambiguous, and frankly uncontroversial.

> it might be

> This is... unambiguous,

How about revenue or moving the needle on a key business metric like churn or order flow conversion rate.

"Synergy" is a precise term as well.

I do have an opinion on the phenomenon. There are more and more mediocre engineers who need this sort of thing in order to justify their existence.

Once the majority is mediocre, it becomes accepted practice.

Reply on news.ycombinator.com