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/...

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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 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.

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)

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.

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.

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.

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.

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.

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%.

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.

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

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.

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.

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.

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.

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!).

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.

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"!

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

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.

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.

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 :)

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

(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 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.

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.

Er, not really. From the article:

> Leverage = Impact Produced / Time Invested

"Impact Produced" has a precise, concrete meaning?

> This is... unambiguous,

:)

Once the majority is mediocre, it becomes accepted practice.