Steve Herrod | Vox

The uproar about the anti-diversity memo may turn out to have been a good thing for Google

2017-08-15T10:23:09-04:00

The outpouring of emotional responses to a now-fired Google engineer’s internal memo about diversity and hiring practices can be painful to read. But contrary to what you might think, this controversy may turn out to have been a good thing for Google — and for every engineering team. I’m glad it’s calling out the myth that only coding prowess matters, and that backchannel gripes about diversity in tech are now out in the open.

I helped grow VMware’s stellar engineering team from 30 to more than 3,000, and I’m now an investor in the next generation of startups. Scaling a team is a complex, nuanced process. It requires diligence, perseverance and open discussion of ideas.

The current controversy may turn out to have been a good thing for Google — and for every engineering team.

Today’s engineering teams are nothing like the old stereotype — a bunch of loner nerd boys who grew up playing video games and tinkering with code by themselves in their parents’ basements. To build successful products, you need a diverse group of personalities: People with strong customer empathy, others who can innovate on user experience, still others with the “brown thumb” for finding bugs before they ship, and those who take pride in fixing those bugs for good. And the personalities you need to hire will change as you grow to 10, then 100, then 1,000 engineers.

No engineer works in solitude today — even a code ninja is part of a team. That’s why you also need people who can keep track of product priorities and schedules, who can make difficult trade-offs, and who have the people skills to keep team members focused on the goals and deadlines that matter. Technical teams also need people who can interface with marketing, sales, operations, human resources, customers and everyone else so that the company, as it grows bigger, stays headed in the right direction. “Soft skills” are just as critical as coding chops.

For a company to scale successfully, its engineers not only must be the best hires, they need to be given paths to develop the aforementioned skills and to grow according to their abilities and interests. And it’s up to technical management to incentivize that development and to establish the best ways to measure that growth.

You need to make moving the company forward a requirement for individual advance. You might set growth milestones for engineers to reach, including some that get them away from their screens and into more extroverted, public roles — publishing papers, giving presentations at conferences and mentoring new team members.

At VMware, we gave cash bonuses for having a paper accepted to present at a top-tier conference, just as we did for patent filing. The pure technical achievement was given the same weight as being able to clearly define and present those technical ideas to a qualified and questioning audience. We also made mentorship an explicit qualification for promotions up the technical ladder. Individual contributors are important, but those who can effectively share knowledge and help shape the skills of more junior technical staff are just as critical.

To build the next Google, you’ll need to create a company that fosters this kind of open dialogue — including complaints about the dialogue that results.

As a manager, you must send a strong signal that communication and organizational skills are equally as important as technical skills, especially as the team grows too big to all know one another. Needless to say, you must set a strong example for this balance as well. VMware created a parallel management career track alongside the technical track, and made clear there was no stigma in switching from one to the other and even back again.

Why do communication skills matter so much? Diversity of ideas is what leads to innovation. Software companies in particular — built on new abstract concepts — take pride in encouraging employees to speak their minds, even when their co-workers resent it. “Everything is up for question and debate,” Google’s SVP of People Operations, Laszlo Bock, asserted not long ago. Free-speech culture and its blowups — familiar to everyone on open source software projects — are the foundation of great software companies.

But this also requires a culture of mutual respect. The loudest complaints on both sides of the ongoing showdown share common themes: My co-workers don’t respect me. My co-workers don’t take me seriously. My co-workers enjoy saying things they know make me feel unwelcome. The challenge for leaders is to maintain openness and respect in parallel as three engineers become 30, then 300, then 3,000.

A successful team is diverse, driven, communicative, vocal … and often argumentative. Imagine a world where everyone shuts up and does their job as assigned. Where you get ahead by not rocking the boat. Where you learn to nod in agreement with the common wisdom. Where there’s never a workplace spat and “disrupt” is a slogan rather than a verb. Those are the companies that have been run off the Internet, one after another, over the past two decades.

If you want to build the next Google, you’ll need to create a company that fosters this kind of open dialogue — including complaints about the dialogue that results. The larger your company gets, the more it will matter. You’ll need to hire a broad range of people and guide them to grow together — even when they fight.

At some point, we’ll be glad everyone has stopped holding back their feelings about diversity conflicts in tech. Remember when Yahoo’s Peanut Butter Manifesto was considered a scandal? Finally we’re talking about the real issues.

Steve Herrod is a managing director at General Catalyst, investing in infrastructure- and developer-centric companies. Prior to joining the firm, Herrod was CTO and SVP of R&D at VMware, where he played an integral role in growing the engineering team to more than 3,000 people. Reach him @herrod.

This article originally appeared on Recode.net.

Connected devices are easily hacked. Why aren’t we holding manufacturers accountable?

2016-10-24T16:44:51-04:00

A man takes a picture of a replica of a Trojan horse made up of thousands of computer and mobile phone components infected with various viruses and malware, displayed at the entrance to the annual Cyber Week conference at the Tel Aviv University. | Jack Guez / AFP / Getty

Last Friday’s daylong cascade of cyber attacks highlighted an issue that until now has largely been a discussion point on security-specific blogs and forums: The internet, and thus much of our modern way of life, is in a precarious state.

DDoS attacks are one of the oldest tricks in the cyber-attack book. Coerce a bunch of unsuspecting machines into sending gobs of data at a target and bam, the target is down. Defenses have gotten better, and there are plenty of services that can deflect run-of-the-mill attacks. But the bad guys aren’t content with sticking to run of the mill.

Cars are recalled for defects and if they fail inspection or smog tests, they’re taken off the road. Why aren’t we advocating the same level of oversight for our shared internet?

Security guru Bruce Schneier warned last month that bad actors are probing some of the fundamental layers of internet technology for vulnerabilities and testing for defense capacities. And security expert Brian Krebs, who reports on vulnerabilities, bad actors and fishy “security” services, experienced one of the largest DDoS attacks seen to date.

That attack may have been the result of hundreds of gigabytes of data per second being lobbed at his site not by hacked computers, but by Internet of Things devices, a botnet living in our shiny new gadgets — things like IP cameras and digital video recorders. And it appears we saw this again yesterday with the attack on Dyn’s DNS service, disrupting popular consumer sites and services like Twitter, Spotify, Sony’s Playstation Network and EA, along with many others.

When the personal automobile hit the roads, it was a free-for-all. If you could buy a car, you could drive said car. There were no rules governing safety or emissions. It took decades before the National Traffic and Motor Vehicle Safety Act was passed, and the National Highway Traffic Safety Administration was created to ensure that vehicles sold were held to safety standards and that manufacturers were liable in the event of malfunctioning features. Once on our shared roads, cars are recalled for defects; if they fail inspection or smog tests, they’re taken off the road. Why aren’t we advocating the same level of oversight for our shared internet?

We’ve allowed just about anyone to ship new attack vectors (a.k.a. IoT devices) with zero responsibility for making them secure.

We do not have decades to wait for the government to create and enforce security standards for connected devices. The internet powers global commerce, communication and innovation. It is critically important to the stability of financial markets and the overall economy. Yet we’re squeamish about enforcing standards that could mitigate some of its increasingly debilitating threats. As a result, we’ve allowed just about anyone to ship new attack vectors (a.k.a. IoT devices) with zero responsibility for making them secure. It’s bad enough that these devices put the owner’s data and privacy at risk, but we’ve just shown that they can also impact our broader shared internet infrastructure.

Good security practices take time, money and expertise (all of which are in short supply) to apply and maintain. Short of us spinning into an altruistic utopia, that willingness will be born out of assigned responsibility — and monetary penalties.

Device manufacturers should be held accountable for their devices’ behaviors out in the wild. Without clear accountability, we’re going to continue shipping easy-to-use yet wildly vulnerable devices. Examples of manufacturer requirements should include:

An end to common default passwords. It’s more work, but every device should start with a different administrative password and require that it be set to an even more secure one when first used in the wild. It sounds obvious, but today you can control a huge number of home devices via a simple search for “default password.”
Impactful alerts for vulnerabilities. These devices will certainly use software that has vulnerabilities, but how does a consumer know these problems are found? Anyone out there constantly hitting refresh on the manufacturer’s device support page to find out? I didn’t think so. Manufacturers must be responsible for getting alerts to their buyers similar to how car makers handle priority vehicle safety recalls. And if the warnings are not heeded within a set amount of time, the device should be disabled.
Self-patching software. Even the lowest-cost camera, Wi-Fi access point or DVR must ship with self-patching software. We can’t have vulnerability-laden devices all over the place just waiting for the bad guys to take them over. And it’s not the owners’ faults — the patching experience for these devices is often miserable, assuming that you even knew it was needed. It’s time to require that these devices meet a minimum standard around simple and automatic patching.
Information sharing. It’s both good and bad news that so many internet-connected devices have so much software in common. It’s bad in that a zero-day exploit can instantly put myriad devices at risk. It’s good in that we can more proactively monitor and protect them using common processes and coordinated patches. Device manufacturers should be required to share findings regarding vulnerabilities and attacks with their peers. Done properly, it can help other manufacturers protect their products and give the cyber security industry a head start in preventing any resulting attacks.

Once upon a time, the prevailing idea was that stringent standards and regulation would stifle the promise of the internet. But as attacks like the ones against Dyn’s DNS service are illustrating, the promise of the internet might very well depend on them.

Steve Herrod is a managing director at General Catalyst, investing in infrastructure- and developer-centric companies. Prior to joining the firm, Herrod was CTO and SVP of R&D at VMware, where he played an integral role in growing the engineering team to more than 3,000 people. Reach him @herrod.

This article originally appeared on Recode.net.