Editorial: Google's 'Rogue Engineer' Policy and Why It Isn't Enterprise Class

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Earlier this week The New York Times reported on the troubling backstory of Google and a recent FCC settlement, which was tied to a charge of scanning consumer Wi-Fi networks to capture private information.

It highlights a practice at Google in which engineers seem to be able to take large corporate risks with little oversight. And given that Google is trying to sell into an enterprise market, that governance model, or more accurately lack of one, should likely eliminate Google as a viable vendor.

The issue isn’t that Google might steal your information; it is that an employee in what is an increasingly complex company could make a decision and implement it without corporate oversight.This means that decisions like this could not only land Google in hot water, as it clearly did in this instance, but it could land a company using the Google solution in hot water or do avoidable damage.

Let’s talk about this as a governance problem, and suggest there is a governance requirement in an enterprise-class vendor.

Defining an Enterprise Vendor

The typical definition of an enterprise-class vender is one that has the hardware, software, and services needed to serve the largest of companies. They also have to have a track record of doing so successfully, which does create a cart and horse problem with new entries like Google.Often this is initially mitigated by working with an enterprise partner, which is what firms like Microsoft, Novell, RedHat, Citrix and even RIM did to get their stature.

Doing it this way made sure there were always experienced teams in charge of assuring the solution. We recently saw an interesting variant in the VCE effort by EMC, Cisco, and VMware, where three enterprise-class vendors partnered to create a new enterprise-class vendor from scratch, largely by pooling their already tested resources.

Behind this definition has always been an assumed robust process for creating, maintaining, and repairing this class of offering that takes into account the critical nature of enterprise tools and assures these massive companies don’t have catastrophic failures.

This isn’t to say enterprise-class vendors don’t make mistakes, they clearly do. But as a class they tend to be far more control-oriented, because the liability, both in terms of cash and in terms of image, is vastly different if a smartphone has a bug or if you shut down Boeing.You may get a class action lawsuit on the former but Boeing is likely to want you to make them whole. And doing material damage to a large company tends to get other firms running for the hills.

I should point out that another often missed aspect of a true enterprise vendor is that their board typically has a large contingent of diverse operating enterprises represented.For instance, if you look at IBM, the quintessential enterprise vendor, you’ll see a large number of CEOs of active enterprises that aren’t in the same business IBM is in.

At Google there is only one such board members, and he runs Intel, a firm that also builds for enterprise customers. The Google board is mostly staffed by investment bankers, not people who have current experience building or selling products in any market Google serves except through their investments.

In fact, when you look at Google’s board, you can imagine they would have governance issues because the board would be more focused on investments Google might make then in how Google was being run. And there is clearly no one on the board, including Intel’s CEO, who represents the voice of the enterprise customer.

The Dangerous 20%

Going back the New York Times piece, the problem with the alleged illegal Google behavior is that the network scanning was created by a “rogue engineer” who built the related application during his 20% personal time.This time was a Google-mandated employee practice intended to encourage innovation. Apparently, according to Google testimony, this happened with no oversight or control.

While it is laudable that engineers in Google are pushed to be creative, it is unconscionable that the result would be allowed to flow to the field without oversight. Google is also live testing self-driving cars. Imagine an ill-conceived notion that these cars not take into account obstacles – or they could roll over, resulting in a failure to stop for pets or even children.

Now given that Google at the top is decidedly light on folks who understand enterprises and is heavily staffed by people who lack much breadth or experience, outside of engineering, this could be very problematic. The image that is conveyed is that at any given time a huge number of the folks are working on projects they weren’t formally introduced into (Milner, the engineer who created the Wi-Fi application was assigned to YouTube, not the organization responsible for scanning networks). And they receive little oversight or direction.

While that practice is likely fine for many startups it creates a chilling scenario for a company of Google’s size and reach.Now if the folks actually running the Wi-Fi program were left out of the loop on this troubling code as a result of this Google practice, how many other lines of business at Google are equally out of control?

The Importance of Governance

We often look at products in depth and at their history in order to determine whether the risks we are taking with them are reasonable. But this revelation about Google’s process suggests we should also look at a firm’s governance. Because if that governance is lacking, there is no way to assure that what we are being kept informed, no matter how truthful the sales rep or technical representative is, because they are not in the loop.

Or, put bluntly, a company with inadequate corporate governance can’t be an enterprise vendor because they can’t assure their own product or service. There are too many opportunities for “rogue engineers” to be able to assure the product will do what is promised and only that.Or, more simply, a governance model that supports “rogue engineers” isn’t one that can support the enterprise.