How Google Handles IT for Its Workers
online.wsj.com
online.wsj.com
Need a new mouse or keyboard? Go and grab one from a nearby tech stop. No need to ask, just swipe your badge and take it. Need something more esoteric? File a ticket and they'll make it happen. I've never had an equipment request denied at Google. The worst that's happened is I've had to wait a few weeks for a particular item to come in stock.
I just don't get why people join these companies I suppose.
Where I used to work RHEL was used on all of the servers. I was part of a team developing some new software using Mongrel2, MongoDB, ZeroMQ, Perl, and Imagemagick ( among a whole collection of other esoteric small pieces ).
The plan for the project was approved and development underway. We encountered problems getting everything to work properly with modern versions of the various parts in the distribution of RHEL provided.
The company was mirroring RHEL, but only the core. They were not mirroring the updates, nor were they mirroring the latest released version of RHEL. Outside access was forbidden on the servers, so we could not fix the problem ourselves without going around network policy.
We requested virtual machines; specifically to use Virtualbox on our desktops to do development until the policy people could figure out how to give us a server with the software needed. We were denied and told we had to requisition a server to run VMs, that VMs on desktop were forbidden.
A $13k server was purchased for this purpose, and root access was denied to it. We couldn't configure it as needed, and IT refused to help. It was basically useless. The main department head approved going ahead with VMs regardless of the network admin and head of software development saying we couldn't.
In the end the project flopped; ultimately due to inability for any of IT to get along or provide what was needed.
The difference is which package versions are approved for use.
For the most part, you can add the yum configuration for CentOS or Fedora to RHEL machines, and install newer packages without breaking it.
Note that some packages will end up pulling in a ton of other dependent packages. By adding a Fedora repo to a RHEL machine, the following things will happen: 1. You will likely lose official support from RHEL. Anything that goes wrong is your fault. 2. Your OS install will start becoming Fedora; as you install more and more stuff. 3. Your setup could break entirely because RHEL packages are not tested to be compatible with Fedora ones. The core configuration is different in places, and generally you should not start updating the core components as this will break things.
My recommendation is to setup the CentOS/Fedora yum repos on your RHEL box. Run yum install for new PostgreSQL and see what yum wants to install. Eyeball the results intelligently and take some guesses as to whether it will break things. Cross your fingers and approve it, then disable the CentOS/Fedora repos you added. Carry on with your life and don't tell IT what you did.
If you can't connect your RHEL machine to outside network, repeat the process somewhere else to figure out what RPMs are needed. Download them elsewhere, and stick them on the RHEL machine and install manually.
As an additional note; I have setup a Fedora repo on a RHEL machine and changed the flag in the system to change the distribution ( there is a core package everything depends on... ). We then updated all, and the resulting system still functioned. Very evil, but it didn't explode. Also; it took quite a while to install all the packages. It essentially is converting the whole system from RHEL to Fedora in place...
IT has valid reasons using RHEL and older packages, you presumably have valid reasons for using newer packages. If newer packages are needed work with IT to get those newer packages. This also means that they are back in the position of being a roadblock if critical projects really can't go forward due to their policies.
Sometimes the way to fix what is broken is to make your department stop being a crutch for failed IT policies.
Also, randomly changing system packages in production is a dick move. That sort of shit is (rightfully) going to result in getting your access revoked at the minimum.
It was either use other components or circumvent IT. The head of the department got fed up with the red tape and told us to circumvent. All proper discussion was done before that, and as a result nothing I did was a "dick move". The system was additionally not in production yet, so no changes in production were being done.
Shame on you for making too many assumptions.
Allowing developers to install and "self-support" a non-supported database version is an _awful_ idea. When shit hits the fan it will be Ops/DBAs who are left to pick up the pieces.
It is hard to argue that using PostgreSQL 9.x is dangerous compared to using PostgreSQL 8.x.
The software requisition process was also terrible. It took 4 months from when I started the job just to get basic software that that is typical for software development. Before that I was directed by my coworkers and superiors to use portable versions of the software I needed secretly.
We all get a sanitized windows 7 shitbox, because a IC deign engineers needs are the same as a secretary (not that we have secretaries anymore).
Saving on them, or are they managers now ?
He has the exact same setup as you and I've never once heard him complain about it. It's really interesting because even though we both work at desks on computers and both do system design and programming, he is so much less in tune with trends in his field. He VNC's to his graphic intensive simulation program on his crappy Win 7 laptop and gets stuff done.
I complain if I can't run several VM's on my developer PC without noticing that they are there.
Why VNC? NX or just plain x11 window forwarding.
Maybe they want all their IC data on a server that gets backed up, etc as opposed to littered on a bunch of random desktops that might or might not be backed up.
We had a centralized Linux server and tape system backing up all the Linux workstations, but they fired the guy who ran that server due to stack ranking; i.e. firing 10-15% of you staff yearly, even though he was a really sharp guy.
IT rules the roost around here, even though we are an engineering company that produces physical items; not software. It's supposed to be the other way around; IT is supposed to provide a service.
http://www.ft.com/cms/s/2/d2f3f04e-6ccf-11df-91c8-00144feab4...
Hah! The Venn diagram depicting people who WANT to do corporate IT at Google, and the people who WANT to use Windows in corporate IT has a pretty small overlap, I think.
I mean, step one, "corporate IT" wants everyone to use Office, and Sharepoint, and then SAP... Yeah, that's just NOT going to happen at Google.
I've read the latest book from Eric Schmidt and Jonathan Rosenberg, where the main argument is "we are the best because we have the smartest people on the planet working for us". That's the main point to explain many of the things that they do.
This article seems on the same line.
But I do hold every hire to the standard of "will this person increase our average capability?" And I think smartness or motivation does have something to do with that. (We also have system administrator level people as our first level support)
However, most companies don't put that level of effort into their IT org. This article is worth reading because it says that your company can benefit by holding the front-line support to a high standard, and paying to attract talented people to that position. That is a radical proposition to most companies. The only thing that could shake up the industry more is if they said they required IT leadership to have technical ability and insight.
Doesn't that just apply to any position?
How many people here serve as tech support for their families? And how many of your relatives are otherwise successful professionals?
For extra fun combine that with not invented here syndrome and retired in place. "Git? whats git? never heard of it. Besides don't you know RCS is the industry standard for version control?" (which was actually pretty much true in 1985) And no this wasn't in '06 this was last year. I'm glad I don't work in that particular team!
And add some inter group politics for extra extra fun.
This was 2001 and everythig was relaxed and pretty open. It wasn't hard to get the software you needed. But that one guy installed Kazaa - bamn, that machine got wiped and re-installed. Another guy brought in a game on 3.5" floppies to play on the pick and place machine - bamn, that machine got wiped by them trying to cover it up, leaving a gently tricky recovery procdure for me to recover all the unbacked up P&P program data.
People who don't know anything about computers might take a few extra clicks to get to what they need but they tend not to break things too badly.
If you're "can use technology" (secretary) you get a completely locked down machine, preferably Linux or FreeBSD with a Web Browser and Google Office or OpenOffice (or whatever it's called now) and that's it.
Windows is built to a large degree for median IT departments. They want to lock it down and give it to employees to use, but not manage.
Obviously this is anecdotal but, Mac users are usually more likely to go into system preferences and try to find out how to arrange their screens or add a printer. Windows users treat control panel as forbidden territory, which IT departments agree with. Installing and installing programs on Windows is more daunting than on OSX, Android, or iOS.
Basically, it's a UX problem. There is no real reason why a PC should not be manageable by a computer literate professional.
There is a happy medium, but IT (largely) is not interested in it. The current system meets their needs very well, but they have lost sight of the needs of their users.
Support was a big deal for this group, and it becomes a lot a easier when every workstation is configured exactly the same way and has the exact same software.
Yeah, unless you are Google, IT equipment sucks donkey balls in the big corps. Especially the banks. Still stuck on IE7 at our one. Sigh.
The example you gave - the pain of sysadmins using the Windows desktop - is perfect. But let me add a different one: the big corp where I work decided that iOS apps were needed. I can't even begin the describe how long and cumbersome the process of acquiring a Mac was! It was so ridiculous that we used personal devices for a time, and then a Hackintosh.
It's one thing having to use Windows for development. I've done it, you can work around lots of issues with Cygwin and other separate tools that enhances the development unfriendliness of Windows. If you are developping in Java, it's even less of an issue as Java itself and most of its IDEs are cross-platform.
But being so locked down that the only thing to do development with is Notepad++ (you can't even run vim or emacs?), that's actually so far beyond that even a complete non-tech person should be able to see that this is harmful to your productivity.
What you do need is a reasonable set of tools to be installed and a quick (under an hour) way to get items installed or updated.
What about a VM ?
Approach it from the tools use, do people use pads and pens or do they use Word?
Depending on the company's hardware VM performance could be a real issue. You'd be surprised how many developer jobs are done on old Windows XP boxes. Big companies typically do upgrades in multiyear cycles.
It's really easy to do if you need it.
I would quit or require a very high payment.
> "I remember years ago, when I joined Google, I looked at the personal technology that Google gave to its people. Google allowed people to use whatever they thought was relevant to them, when everyone else gave people a black laptop and a BlackBerry and said, “You are going to do it our way."
So I have this dinky little HP with a 15" monitor just to do the HR computer "training" stuff related to our industry and then I have a full size workstation with dual 24" monitors that I develop on. They're connected to different networks, my workstation is on a Comcast business line and then the other is on an internal network that has the strictest security policies on the planet.
It's like having a weird cross between IT as it should be (as described in this article) and IT hell you expect in large corporations.
> We can’t afford to have technology support where there are cookbooks and rules and every possible change is documented in advance
There's something ironic in that...
This means that people are more productive when they have the hardware and software they are used to.
Interoperability would surely take a hit, and imagine the IT support required.
/sorry for the sarcastic stereotyping...
Also you are going to get Linux if you are doing i.e iOS development. See the point ?
That's what Google threw into the trash and solved their problem.
http://www.ubuntu.com/certification/
;)
What do you tell the Mac user? What do you tell the Linux user? Boot a VM whenever you want to work on a document? What do you tell the iPad user?
In many large organizations, simple file systems won't work because they don't scale and you can't tell a legal department "oh, you need to share/version/distribute documents? just use this program called git, it's easy, let me show you and once you've got the hang of it, you call the appellate judge and tell him that he just needs to do a git pull to get your brief".
When every software package that's deployed in millions of installations around the world that's only available in the Windows/Office/IE environment is completely cross-platform, then yes, you'll have completely interoperability between Windows, Mac and Linux machines, as well as iOS and Android devices. Until, the "I've had Mac, Linux and Windows machines on a home network" line has no bearing whatsoever on intolerability of software packages an enterprise environment that needs to interface to hundreds of external organizations daily.
I've been working for quite some time, at small and large companies, and I've never had to use a document management system.
Well, we know at least 2 Fortune 500 companies that haven't had a problem: Google and Apple.
Yes.
With the horsepower the machines are putting out nowadays and the ease of which a VM can be initialized, that is neither a hindrance or a burden when compared to the luxury of using your native OS.
Otherwise the Windows guy can't check in because he can't get git+ssh+pgp working right to do signed commits; the Linux guy can't run the CUDA part of the code because the drivers for his distro are broken; and the Mac guy keeps on having homebrew and ruby break and no-one else on the team knows anything that can help.
Better yet, schedule a "brown bag lunch discussion" around the article, and invite your boss as well as several of your colleagues.
Your corporate culture is something you must work within, but it is also something you can change -- or at least affect.