[A lot of people seem to be entering my blog for the first time through this post. Welcome! If you'd like to be kept updated about future posts, feel free to follow me on Google+]

As those of you who know me through other media or in real life are aware by now, I'm starting a job at Google (again!) after just over a year at IBM Research.

So, why am I going back? I'm reminded of the bit at the start of Steve Yegge's infamous rant about Google and platforms (the original blog post is down, but has been kept up elsewhere for posterity). Just before tearing apart Google's platform strategy, Steve softened the blow by saying this:

One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.
(Steve Yegge, in case you were interested, writes very amusing yet intelligent rants about interesting topics )

So anyway, does IBM do everything wrong? I'm not going to answer that, partly because I don't feel qualified to do so. The company is going strong 101 years and counting, so there must be plenty of 'right' in there. What I can say is that, in my experience, Google does everything better. Not just better than IBM, but better full stop. If you look across the whole world of large corporations, I can't imagine that there are many that make a better environment than Google for a software developer. Google's awesomeness as a place to work breeds a certain sense of complacency and whiney entitlement on the inside that is best cured by spending a bit of time at a normal company. I always had a pretty good time there, but did perhaps spend a little too much time fixating on how the vegetarian options at lunch left something to be desired rather than delighting in all the awesomeness around me. Seeing how other places function (and I'm confident that IBM is not an unusual environment in any way) has definitely sharpened my perspective about what made Google so good.

Having dodged the negative question, being the sort of positive dude that I am I will now list some of the things that personally I have missed the most about Google during my absence from the company. This is going to be done over two posts. Today I'm going to cover the tools, the culture and the management. Friday I'll come back to discuss Google's immense scope, its great people, and (of course) the ridiculous perks. Some disclaimers:


  1. These are all generalisations and exceptions exist.
  2. My perceptions are coloured by my specific experience as a software developer, on particular projects, in particular offices.
  3. In none of this do I represent Google (or IBM, for that matter). These are my personal opinions only.

Anyway, let's get on with it.

The tools

I'm not sure what it says about me, but I often find myself profoundly affected by mundane matters of infrastructure. When asked I liked best about Zurich, I had to swallow my shame and say "the public transport". And this wasn't because I disliked Zurich! There were heaps of things that I liked, but somehow the infrastructure seemed to be the single thing that mattered most. Good infrastructure reduces the friction of living one's life, and makes nearly everything you do more pleasurable. Living in Australia after Zurich made me realise how inadequate the transportation infrastructure is here. And so it was with surprise but also a hint of recognition that the first things I started missing about Google were not all the glamorous things but its truly incredible tools, infrastructure and support.

On my first day at IBM, I had to grapple with Lotus Notes (an experience as unpleasant as everybody said it would be). On the second day, I discovered that we had no version control repository set up in the lab and that if we wanted one, we would have to set up and administer it ourselves. Within a couple of weeks I learnt that our tools were going to be no better than the best open source tools that we could administer ourselves, and often quite a bit worse. Want version control? Set up svn. Want to store some data? Set up db2. Want to run a mapreduce? Set up Hadoop. Want your data backup? Set up and administer a backup system. Want to run Tomcat? Perhaps you should consider IBM Websphere Application Server instead. And by the way, install it yourself. Did you say you used svn? You should have gone with IBM Rational Team Concert. And so on.

People talked about "the cloud" nonstop, but collaborated on documents by emailing .doc files around and manually merging changes. IBM owns a Class A IP allocation, but I kept running out of IP addresses to asign to new servers. Bureaucratic tools were Java applets if we were lucky, or Lotus Notes "databases" if we weren't. Technical support was nonexistent, but technical bureaucracy was rampant. Didn't like something about a piece of IBM software? Good luck finding a place to provide feedback.

Anyway, I said I wasn't going to rant about IBM. Oh well, too late now. My point is this: I didn't have to worry about any of this shit at Google. My email was Gmail, we collaborated by using Google Docs. Our intranet was fast and reasonably searchable. There were amazing globally-administered revision control and build tools. Great testing and release infrastructure. If I wanted to start a mapreduce, I hit 'enter'. Internal bureaucratic tools were all web apps, and all tolerable or actively good. Internal applications all had quick feedback links or queues in the ticketing system. Whole teams provided me with services for data storage, compute, load balancing, and many other things. SRE's did an incredible job keeping software up and running. Tech Stop were always there to quickly and competently solve any computer or networking problems I had.

I didn't really notice any of this stuff, precisely because good tools and infrastrucure reduce friction. Once the tools disappeared, I felt that most of my work life was friction.

The things I complained about then ("I can't believe my 10,000-worker mapreduce took 25 minutes to start!") seem ridiculous now.

The culture

There are a lot of things to love about Google's culture, from its sense of fun to its sense of adventure to its open communications, but I'd like to focus on one in particular: its intolerance to bullshit. Google has a culture of intellectual honesty that focuses on what's right and what makes sense, rather than what sounds good. Things that do not go over well at Google: hiding behind titles or qualifications; grandstanding to make accomplishments seem more significant than they are; using vague jargon and industry buzzwords to cover an absence of real meaning ("the enterprise faces a tipping point in big data and must embrace advanced cloud technologies and end-to-end real time analytics"). 

 At Google, expect everything to be challenged. If your meaning is not clear, you will be asked to clarify it. If you're making a mountain out of a molehill, you will be cut down to size. And if you're talking a load of bollocks, you will be called out on it. Even if you're a Director. Due to their intolerance of bullshit, Googlers can be perceived as blunt or rude, but I perceive it as awesome. It's amazing the amount of difference a cultural intolerance to bullshit can make. It's like some sort of solvent that stops inefficiency and waste from building up in all the nooks and crannies of the organisation. Strategies are questioned and therefore improved. Dead weight does not make it into management. Pointless bureaucracy is squashed. The reality of the company's business and its own perception and projection of its business are kept in much closer sync when bullshit is eliminated. Trust grows, and politics shrinks. Good people don't leave in frustration.

 I've learned that I have a very low personal tolerance for the posturing and politics of bullshit. Therefore, I will value Google's low-bullshit culture even more this time around.

The management

I know that a lot of people think that the quality of management doesn't make much difference to a work environment, but I think otherwise. There are always bad apples, but on the whole Google has an effective and responsive management organisation that is dedicated to helping individuals and teams achieve their goals (and I'm not just saying this because I used to be one of them!). Clear communications are valued, and problems taken seriously. Leadership is by example, not by authority. If a team is unproductive for any reason, the manager of that team sees it as their problem to help improve the situation. Technical managers are drawn from the technical ranks, so they are never clueless PHB's and usually have their teams' respect.

Part of what enables this excellent management culture are the frequent opportunities people have to provide feedback on and to their managers about their performance. This helps keep managers accountable up the line, but more importantly provides valuable input that helps them do their job better. As a manager, I often felt that people wouldn't tell me directly if they felt I wasn't doing a good job on something. The existence of various forms of structured and often anonymous feedback gave me great insight into what I needed to to better. Likewise, I made sure to always put thought into how I could provide valuable feedback to my own managers.

In summary: managers were less like "the boss" and more like a part of the team whose job it was to make sure you were happy and productive.

UPDATE: The second half of this article is now live. Click here to continue through to it.

Posted by
Labels: google opinion software development work
4

View comments

  1. Welcome back! It's not as idyllic as you remember it though :-) It's a great comparison and reminder.

    ReplyDelete

  2. Now I'm afraid of the outside world ;)

    ReplyDelete

  3. Welcome back! Also, you should try enabling g+ comments on your blog from the blogger dashboard!

    ReplyDelete

  4. That’s truly interesting post. Even I am going to attend the online marketing classes so that can be able to promote my small business. Recently I am availing only the facebook ads services but will start the SEO and PPC campaigns on my own. Hoping to find a good course that can help me learn everything from scratch.

    ReplyDelete

  1. I've seen quite a few news articles lately that blindly repeat assertions from the insurance industry about how people in Australia are underinsured. The implication seems to be that if you aren't fully insured against every possible eventuality, then you don't have enough. This irritates me, because people rarely talk about the true nature of insurance. Insurance is gambling.

    Insurance isn't just 'like' gambling, is is gambling. In particular, it's a very particular type of gambling where you are betting that something bad will happen to you and the insurance company is betting that it won't. Replace the word 'premium' with 'wager' and it all becomes pretty obvious. Now, one truism about gambling is that on average the house always wins. If the odds weren't stacked in the favour of the house, there would be no house. And last time I checked insurance companies were pleasantly profitable.



    Now, betting that something bad will happen can be very useful, as it provides a form of hedging, or smoothing, of the statistical variance of life. If something really bad happens, at least you win your bet with the insurance company and this can help you out of trouble. The other side of the equation, though, is that for as long as you avoid major misfortune, you're losing bet after bet with the insurance companies. This in turn puts you financially behind, which makes you more vulnerable to financial setbacks, which in turn makes it more necessary than ever to retain insurance. Perfect! (for the insurance companies, that is)

    So, in the face of all this propaganda about underinsurance, what is the right amount of insurance to get? In my opinion, the answer is: as little as possible. In particular, you should only insure against events whose financial impact would be ruinous to you, and even then the insurance should be sufficient only to avoid said ruin. Basically, if you can afford to take the hit of a potential misfortune, you probably shouldn't be insuring against it. For this reason, insurance with a high excess/deductible/franchise is generally a good idea. In return for significantly lower premiums, you can insure only against catastrophic events. Say you have house insurance with a $2000 premium. For small mishaps, you're effectively not covered. Too bad. But if your house gets hit by a cyclone, the insurance covers all but the first little bit of the damage. You won't be ruined.

    Insurance is valuable when you are facing potential uncapped liabilities, such as with third-party car insurance (who knows what you may hit?) or with health, especially in countries with a weak social safety net such as the USA. Taking out some insurance to make sure that your not faced with multi-million dollar bills (say, if you hit a truck full of Ferraris) makes good sense.

    There's something that a lot of big companies do that is called self-insurance. That makes it sound scary, but individuals can do it too: self-insurance is just a fancy word for saving for a rainy day. With all the money you save on insurance premiums, you can build up a big buffer that you can draw upon whenever things go wrong. Statistically, you'll come out ahead this way. Of course, you need to have the discipline to actually save the money you would have spent on premiums for this to work. Also, if you have a particularly bad run of luck, self-insuring may well leave you worse off than if you had insurance. But that's the nature of gambling: sometimes you win big, but more often than not you don't. As long as you've insured against the big things as mentioned above, even a run bad luck won't come close to ruining you.

    There are a couple of exceptions to the principle of minimising your insurance cover. The first is that it may make sense to take out insurance if you know something material that the house doesn't, or that it doesn't take into consideration, as that may tilt the odds in your favour. Consider the case of car insurance: if you happen to know you're a particularly bad driver, but for some reason your demographic profile shows you to be low-risk, you may come out ahead in the long term by taking out comprehensive car insurance.

    The second exception is if the odds are warped in your favour by government regulation. This is particularly prevalent in the area of health insurance. In Switzerland, for example, health insurers are obliged to provide basic cover to all comers, and are not allowed to adjust the premiums for higher-risk members. Hence, if you have a health issue, taking out insurance is a bet you're nearly guaranteed to win. In Australia, people above a certain income threshold pay additional tax if they do not have health insurance. This has the effect of making the premiums less expensive (as they are subsidised by the removal of the tax penalty) and so again renders the insurance good value.

    Insurance companies have a strong ally in selling their product: fear. Just as traditional gambling uses aspiration as its pitch, insurance panders to all our fears of things going wrong. Remember, just because they're "there for you when times are tough" does not mean that they're the good guys. For each type of insurance, think about whether your fear is rational. If it isn't, keep your money in your pocket.
    Posted by
    14

    View comments

  2. I've actually managed to largely avoid having to anything to do with Javascript until I rejoined Google a few months ago. My current project is the Google Maps Javascript API... so I've been learning fast!

    Lots of people like to complain about how Javascript is a crappy language, so I was expecting it to be. What I actually found was a pretty decent functional-ish language hidden under the clunky syntax. As the page for Coffeescript put it:

    Underneath that awkward Java-esque patina, JavaScript has always had a gorgeous heart.

    Indeed, and Coffeescript does do a nice job of exposing that heart. But even in its awkward clothes, and not withstanding some very valid criticisms*, I've found Javascript to be a pretty decent and even a fun programming language. A lot of what people think they hate about Javascript are really things they hate about web programming: the DOM, or browser compatibility hell. In any case, I think most of these other issues pale into Javascript's one big problem: it's weakly typed.

    I DO NOT LIKE WEAKLY TYPED PROGRAMMING LANGUAGES.

    I should qualify that, of course. Weak typing ins't something that happens by accident: in fact, it requires quite a bit of cleverness in the runtime, and it certainly makes small scripting tasks quite a lot quicker and easier. For scripting languages, I have not problem with weak typing. You may ask: it's called Javascript, so what's the problem then? Well, it may have been envisaged as a scripting language, but for better or for worse Javascript powers the web, and it is being used to build full-scale applications of ever-increasing complexity. From my Python programming days, I know what happens when you try to develop complex full-scale applications in a weakly-typed programming language: bad things happen. Static checking finds far fewer problems than it does for strongly-typed languages, and unless well-considered documentation conventions are rigorously adhered to, figuring out what a piece of code is meant to do can be extremely painful.

    Luckily, at Google we have a solution: the Closure Compiler. It is a compiler for Javascript that does all the nice things compilers do (e.g. optimisation, dead-code removal) before outputting a Javascript package that is typically much smaller than whatever you fed into it, and often much faster too. In my travels around the web (my current project requires me to spend quite a lot of time looking at the JS used by other sites), I've been shocked by how many large and reputable sites fail to even use a minifier on their code. Apart from the potential for code theft if you care about that sort of thing, this is foing a great disservice to the site's users: on the web, larger code leads directly to longer load times. Minifying your JS is one of the quickest and cheapest ways to give your users a better experience on your site.

    Closure Compiler is more than a minifier, though. Amongst its many tricks it also introduces a type system to Javascript. Actually it's more than a type system: it also allows you to declare the visibility of object properties, for example. Javascript typing in Closure is achieved using JsDoc comments, which means the actual Javascript syntax is unaltered and can still be run by any Javascript interpreter. Here's an example of a JsDoc type annotation:

    /** @type {boolean} */
    var isBroken = true;

    Now, if you try to assign a number to isBroken, the compiler will warn you. Functions become much easier to read, too:

    /**
     * Check whether a number is prime.
     * @param {number} myNum  The number to check for primeness.
     * @return {boolean} Whether the number is prime.
     */
    function isPrime(mynum) {
      ...
    }

    And of course, if you try to pass a string into isPrime, the compiler will alert you to that, too.

    Closure Compiler turns Javascript into a real programming language, and I love it for that. The great news is that it's completely free for anyone to use, so if you're developing a complex website or web application, I'd suggest giving it a go today.


    *My aim here isn't to start a language war. If you think JS sucks, fair enough... there are good reasons to dislike it. Closure Compiler still makes is better.
    Posted by
    0

    Add a comment

  3. There's been quite a lot of debate, both internally and externally, about Google's new unified messaging service (somewhat confusingly called Hangouts). I'm not going to enter into a discussion of the merits and demerits of this particular rollout, but I did want to discuss one particular class of criticism: that the new service is not feature-equivalent with the old service (gtalk), and that it therefore breaks a bunch of workflows and use-cases that have developed around the old product.

    And let's not even mention Google Reader.

    As an organisation, having users is a nice problem to have, but it is a problem nonetheless. Existing users are change-averse, for a variety of good reasons. Dealing with change is an additional cognitive burden; changes to a product can break existing workflows or make them less efficient; changes might significantly disadvantage some users; if the product is a platform, the changes might break existing applications. And of course, we have it on the highest authority that every update breaks someone's workflow.

    I have no beef with the people who complain about all the legitimate ways that a change broke them (hell, I do it myself), but I can also see this from the perspective of a company providing a service. What happens if a company commits to never breaking things for existing users? They start diverting more and more resources from staying at the leading edge of the market to simply maintaining compatibility. And while such commitment to existing users is admirable, it leads to escalating costs both for maintenance and development of new features (because those new features must be compatible). More egregiously, it complicates and compromises product decisions, preserves old mistakes for all time, and almost inevitably slows the pace of innovation.

    The stone slows down; it gathers moss; eventually it stops altogether. Meanwhile (and apologies for the mixed metaphor) the world keeps moving past this organisation and its products. The day comes when the company simply loses relevance. In servicing its existing user-base, the organisation has ceded progress and innovation to others, and eventually those existing users will make the move to the newer, better, shinier thing.



    This problem is a variant of the Innovator's Dilemma, but applies more to product decisions rather than commercial ones. Organisations are in a very difficult position, but if they want to survive in the long term they have only one choice: gather no moss. As Stalin once said, "if you want to make an omelette, you have to break a few eggs". Just because he was a genocidal maniac doesn't mean he was wrong*. Sad as it is, companies need to be prepared to upset existing users in order to maintain a suitable pace of innovation. This is not to say companies should have carte blanche to make frequent and unnecessary changes to their products; all changes should be made carefully and thoughtfully. But, the amount of existing legacy must be strictly managed if an organisation is to hope to serve its users in the long term.

    All this does of course raise the question of whether shareholder-beholden private companies are a suitable vehicle for providing sustainable and reliable service over the longer term. As long as their pseudo-biological imperative for growth and self-preservation overrides other considerations, it would seem to me the answer is no. However, Stalin quotes notwithstanding, I can't think of any other way that would do a better job. I guess we just have to suck it up.


    *OK, and it seems he probably didn't even say it. Oh well.
    Posted by
    0

    Add a comment

  4. If you've had any exposure at all to large bureaucracies, you will probably know that KPI stands for Key Performance Indicator, which is just a fancy term for a way of measuring how well you're doing at something. If, on the other hand, you haven't had any exposure at all to large bureaucracies, congratulations! Keep up the good work.

    Anyway, KPIs have always bothered the hell out of me. In fact, the title of this post was going to be "KPIs are a load of bollocks," but I chickened out. My basic thesis is this: show me a performance metric, and I'll show you a performance metric that is being gamed. The basic problem with any KPI is that it is a simple, abstracted measurement of a more complex underlying phenomenon. For example, you might measure the productivity of a call center worker by the number of calls they complete per hour. This seems reasonable; one would expect the productivity of the worker to correlate with this metric. The problems begin, however, when the KPI is used as a way of rewarding and motivating workers.



    I always remember a story told to me by an Associate Professor at the Computer Science Department of RMIT University, where I was doing my PhD. This particular person's research area was Genetic Programming (GP), which endeavours to 'evolve' programs to perform a particular task (usually in LISP) by using analogues of the processes of survival of the fittest, mutation, and sexual reproduction. Anyway, one of things he was involved with was the Robocup software league. Essentially, he and his team were trying to evolve programs that could successfully play a game of simulated soccer.

    Now, in order to get the 'survival of the fittest' part of GP working, one needs a 'fitness function' that determines how successful a particular program is at performing the task towards which the evolution is targeted. In other words, a KPI. In the case of Robocup, this Associate Professor explained to me that at first they had tried to use the number of goals scored by each player as the fitness function. This makes sense, as better players would tend to score more goals. The problem was that the fitness function wasn't granular enough; the randomly-generated players were so far away from being able to score a goal that the evolution ended up being essentially undirected. So, the clever researchers came up with a more granular fitness function: fitness of a player will be a product of the time spent in possession of the ball and the inverse of the distance of the ball from the goal. Again, this seems to make sense: good attacking players get the ball near the goal. This provides a smoother runway to evolve players that can attack a bit, but not well enough to get an actual goal, on the way to getting to goal-scoring behaviour.

    You may be able to guess what happened next. After the evolution was complete, the researchers ran a game of simulated soccer with the most highly fit specimens evolved during their run. This is what they observed: a player would take the ball, move it towards the goal, and just before actually getting it in they would stop and hover around the ball, stopping other players from getting to it. In other words, they optimised very successfully for the KPI, but not for the actual goal. In fact, the players were disincentivised from scoring an actual goal, as this would take the ball from their possession and move it away from the goal. Anyway, the researchers tried with several different fitness functions, and each time a different undesired and unexpected behaviour emerged to take advantage of the metric. Throughout all this, the players did all sorts of interesting and clever things. But they never kicked a goal.

    It's not very hard to see that our call center workers above, if their pay or career prospects depended on a calls-handled KPI, might start to act funny. For example, they might begin to terminate many calls before an issue is resolved, in order to be able to receive more calls. This is not a made-up example. When you rely on KPIs too heavily, weird (and usually bad) things happen. In particular, if incentive structures are built around particular KPIs, you are guaranteeing that the organisation will maximise those KPIs. If the KPIs are not very closely tied to what you actually want to achieve, it is most likely that the KPIs will be maximised at the expense of that ultimate goal.

    In software development, most obvious KPIs end up encouraging poor behaviour: lines of code written, number of changes submitted, number of bugs resolved, and so on all end up forcing people away from optimal development. LoC count for example, can encourage unnecessary verbosity and copy-paste coding. It is essential to have management with actual insight into the contribution of each person rather than relying on cheap and gameable metrics.

    Bottom line is this: management by KPI is mismanagement. KPIs can provide a valuable snapshot of performance if used with care, but in my opinion tying them into an incentive scheme is simply asking for trouble.

    Photo by Vitor Castillo / CC 2.0
    Posted by
    Labels: management opinion work
    2

    View comments

  5. This is the second of a two part series about what makes Google a great place to work, so I shall skip the preamble and dive right into some of the other things that I really love about Google:

    The scope

    We're in cliche territory here, but there's no avoiding that it's true: Google likes to think big. At no point on any project there did I feel I was just working on a little toy system that wouldn't make much of an impact. Even relatively small features that I worked on like Real Estate Search were likely to be used by hundreds of thousands, if not millions, of people. On the resource side, too, the amazing ease with which you could start a computation using tens of thousands of CPU cores and terabytes of RAM was quite intoxicating. Easy to forget, but always amazing once remembered.

    Google still does quite a lot of "because it's there" type thinking. Although there's certainly much more of a product focus than there used to be such that individuals can no longer do whatever they want  (something many Googlers complain bitterly about), Google often pursues new areas of innovation without a clear idea of what the payoff will be. Like with NASA, the payoff often comes in the many tangential solutions developed in order to reach the final goal (dustbusters, anyone?). This is especially true of Google X, who are responsible for self-driving cars and Google Glass and what not. 

    The thinking carries throughout the organisation, though. I still remember questioning a Director about a massive and expensive expansion in the size of Google's web-search index. This expansion was not backed up by numbers that could show improved search quality as a result of the larger index. The Director's attitude was simple: the web is growing, you have to stay ahead of the curve. And also: not all improvements can be measured; Google's goal should be to index as close as possible to everything that's out there, and that's exactly what he was going to do. It seemed strange at the time, but now it feels exactly right. Do everything as big and as well as you can; the benefits may not be obvious now, but they will be realised eventually.

    The people

    Many companies have plenty of good or even great people working for them. IBM certainly did, and I learnt a lot from them. What's different about Google is that nearly all the people are good and intelligent people, and they are empowered to do their job properly. Not just within engineering or the technical organisation, but across all the functions: sales, marketing, HR, admin assistants, project managers, technical support, recruiting, the works. What does it mean when (to pick a random example) HR is not staffed by a bunch of idiots? They become no longer an organisation to be worked around and avoided, but rather a partner that helps you get things done. Not happy with an aspect of recruiting procedure? Talk to a recruiter; they may just be able to get it changed. When you no longer dread having to deal with segments of your own company, life gets quite a bit better.

    I exaggerate a bit here; of course there is dead weight at Google, and the company could arguably do a better job of moving people on, but the percentage of good people across all functions is much much higher than anywhere else I've encountered.

    There are, I think, a few reasons for the goodness of the people. The fact that the company probably spends more money per employee (salary, perks, office fitout, etc.) than most others certainly helps, especially in areas that could otherwise be cheaply outsourced (e.g. basic HR services). Keeping nearly everything in-house and hiring qualified professionals to do every job makes a big difference. Another thing that's important are the rigorous processes around recruiting and promotion. In both cases the decisions are made by committees; while in most cases committees are horrible things to be feared, when making hiring and promotion decisions leaving it to a group of people who have no vested interest in the outcome (unlike, for example, the hiring manager) is an eminently good idea. The fact that HR keeps an obsessive data-driven reign over the whole process makes things even better.

    The most important thing in my opinion, though, is that good people attract good people. Google started on the right foot, didn't lose sight of the importance of good people, and the whole thing has been snowballing ever since.

    The perks


    I thought about whether to list the perks as one of the great things about Google. It seems like a theme that's been done to death, and it's not one of the things that makes Google a great place to work in the following way: Google without the perks would still be awesome; a crappy workplace with Google's perks would still be crappy.

    But still, there's no denying the perks add to what makes Google special, so they made the cut.

    You can go to any number of sources on the web to find out about Google's perks. There are free (very good) meals, rooms full of snacks, drinks, and coffee, massages, slides, fireman poles, couches, sleeping pods, gaming rooms, relaxation rooms, dual 24" monitors, exciting team offsite events, Christmas parties, beer on Fridays, 20% time to work on projects of your choice, and more besides. A real embarrassment of riches. And though as I explained above these perks are neither necessary nor sufficient for Google's goodness, they present a general sense of the company's generosity that (apart from the immediate benefit of the perks) makes one feel valued as an employee. It's the icing on the cake, and it makes each day a bit more pleasant and exciting. One thing one never feels about work at Google is that it's drab, or that you're being taken advantage of.

    Now, I've seen some commentary around Google's perks along the lines of "Google only provides all these perks to manipulate people into spending more time at work, boo Google". This strikes me as unnecessarily cynical. Nobody is forced to (for example) stay late for the free dinner; if they want to, and end up spending longer at work because of it, that's called a win-win. There's never any pressure to do so. Don't get me wrong, I understand that Google is a for-profit company and has instituted policies that help retention and productivity. But to therefore reduce everything it does into a cynical exercise in manipulation is to misunderstand the mutual benefit that exists in a company having a happy workforce.

    The openness and trust

    Google's a bit of a bunker from the outside; many people are surprised when they first start there at how open the company is internally. In fact it turns out that the strong sense of secrecy with the outside world is maintained in order to allow a culture of trust and openness internally. At Google, most people have access to most information about most things. With certain exceptions, it is possible to browse detailed project pages describing other teams' work, and to view the source code of other projects. Executive decisions are usually given along with a rationale, rather than by simple fiat. Larry and Sergey even tend to be around at TGIF in Mountain View to answer any questions employees may have about the company. Generally, the culture is "open by default" which, when combined with the intolerance for bullshit described in the previous post, means that ordinary employees have unusual insight into what is going on at the company, all the way up to the highest levels.

    Being as open as Google is internally requires a great deal of trust in employees, and trust is really something that runs throughout the company's ethos. People are generally empowered to make sensible decisions without having to run up the management line for permission about everything they do, whether this is making a decision to fix a bug in a certain way or purchasing a particular item to help in developing a project. Even Legal are there more to give advice and to help than to say "no" to things (there are exceptions, of course!) The culture is one of asking for forgiveness rather than permission. If you screw up or are found to be wasteful, you will be held accountable for that. Until then, nobody will really question your decision to do release a particular version of a product, go on a trip, buy an item, etc. As a result of this, more things go wrong at Google than at most places, but in my view the tradeoff is highly beneficial.

    (Note that Googlers may take issue with the above characterisation. There are certainly approval processes, in particular around launching new products, but nonetheless an unusual degree of liberty remains.)

    In my mind, trust is the only truly effective way to run a high-functioning company such as most companies in the technology space. The alternative, which is processes, approvals, and metrics, severely reduces productivity and stifles the ability of an organisation to innovate and to take risks. I find metrics (or "KPIs" as they often seem to be called in enterprises these days) particularly toxic: rare is the KPI that cannot be gamed; in nearly all cases ruling by KPI means that you optimise for the KPI rather than for the underlying business objective. The two are rarely the same, and it's hard to notice until it's too late. A topic for a future blog post, perhaps.

    So anyway,  how did Google achieve its culture of trust without it being terribly abused? There's no magic trick. Hire good people, give them a sense of identity with the company, make it so they love to work there, and provide a modest level of oversight. Don't micromanage. Make sure performance is measured in as accurate as possible a way (notoriously difficult, but peer reviews certainly help). Self interest and social pressure will do the rest.

    In conclusion

    Google is not perfect. There are bad projects, bad processes, bad people, bad days. Sometimes things happen that are complete counterpoints to all the great stuff I listed above. I certainly didn't come home from every day of those five years at Google with a spring in my step and a song in my heart. But, just because it isn't perfect doesn't mean that it isn't damn good. It is. And I'm glad to be going back.


    Photo by Marcin Wichary CC 2.0


    Posted by
    1

    View comments

  6. [A lot of people seem to be entering my blog for the first time through this post. Welcome! If you'd like to be kept updated about future posts, feel free to follow me on Google+]

    As those of you who know me through other media or in real life are aware by now, I'm starting a job at Google (again!) after just over a year at IBM Research.

    So, why am I going back? I'm reminded of the bit at the start of Steve Yegge's infamous rant about Google and platforms (the original blog post is down, but has been kept up elsewhere for posterity). Just before tearing apart Google's platform strategy, Steve softened the blow by saying this:

    One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.
    (Steve Yegge, in case you were interested, writes very amusing yet intelligent rants about interesting topics )

    So anyway, does IBM do everything wrong? I'm not going to answer that, partly because I don't feel qualified to do so. The company is going strong 101 years and counting, so there must be plenty of 'right' in there. What I can say is that, in my experience, Google does everything better. Not just better than IBM, but better full stop. If you look across the whole world of large corporations, I can't imagine that there are many that make a better environment than Google for a software developer. Google's awesomeness as a place to work breeds a certain sense of complacency and whiney entitlement on the inside that is best cured by spending a bit of time at a normal company. I always had a pretty good time there, but did perhaps spend a little too much time fixating on how the vegetarian options at lunch left something to be desired rather than delighting in all the awesomeness around me. Seeing how other places function (and I'm confident that IBM is not an unusual environment in any way) has definitely sharpened my perspective about what made Google so good.

    Having dodged the negative question, being the sort of positive dude that I am I will now list some of the things that personally I have missed the most about Google during my absence from the company. This is going to be done over two posts. Today I'm going to cover the tools, the culture and the management. Friday I'll come back to discuss Google's immense scope, its great people, and (of course) the ridiculous perks. Some disclaimers:


    1. These are all generalisations and exceptions exist.
    2. My perceptions are coloured by my specific experience as a software developer, on particular projects, in particular offices.
    3. In none of this do I represent Google (or IBM, for that matter). These are my personal opinions only.

    Anyway, let's get on with it.

    The tools

    I'm not sure what it says about me, but I often find myself profoundly affected by mundane matters of infrastructure. When asked I liked best about Zurich, I had to swallow my shame and say "the public transport". And this wasn't because I disliked Zurich! There were heaps of things that I liked, but somehow the infrastructure seemed to be the single thing that mattered most. Good infrastructure reduces the friction of living one's life, and makes nearly everything you do more pleasurable. Living in Australia after Zurich made me realise how inadequate the transportation infrastructure is here. And so it was with surprise but also a hint of recognition that the first things I started missing about Google were not all the glamorous things but its truly incredible tools, infrastructure and support.

    On my first day at IBM, I had to grapple with Lotus Notes (an experience as unpleasant as everybody said it would be). On the second day, I discovered that we had no version control repository set up in the lab and that if we wanted one, we would have to set up and administer it ourselves. Within a couple of weeks I learnt that our tools were going to be no better than the best open source tools that we could administer ourselves, and often quite a bit worse. Want version control? Set up svn. Want to store some data? Set up db2. Want to run a mapreduce? Set up Hadoop. Want your data backup? Set up and administer a backup system. Want to run Tomcat? Perhaps you should consider IBM Websphere Application Server instead. And by the way, install it yourself. Did you say you used svn? You should have gone with IBM Rational Team Concert. And so on.

    People talked about "the cloud" nonstop, but collaborated on documents by emailing .doc files around and manually merging changes. IBM owns a Class A IP allocation, but I kept running out of IP addresses to asign to new servers. Bureaucratic tools were Java applets if we were lucky, or Lotus Notes "databases" if we weren't. Technical support was nonexistent, but technical bureaucracy was rampant. Didn't like something about a piece of IBM software? Good luck finding a place to provide feedback.

    Anyway, I said I wasn't going to rant about IBM. Oh well, too late now. My point is this: I didn't have to worry about any of this shit at Google. My email was Gmail, we collaborated by using Google Docs. Our intranet was fast and reasonably searchable. There were amazing globally-administered revision control and build tools. Great testing and release infrastructure. If I wanted to start a mapreduce, I hit 'enter'. Internal bureaucratic tools were all web apps, and all tolerable or actively good. Internal applications all had quick feedback links or queues in the ticketing system. Whole teams provided me with services for data storage, compute, load balancing, and many other things. SRE's did an incredible job keeping software up and running. Tech Stop were always there to quickly and competently solve any computer or networking problems I had.

    I didn't really notice any of this stuff, precisely because good tools and infrastrucure reduce friction. Once the tools disappeared, I felt that most of my work life was friction.

    The things I complained about then ("I can't believe my 10,000-worker mapreduce took 25 minutes to start!") seem ridiculous now.

    The culture

    There are a lot of things to love about Google's culture, from its sense of fun to its sense of adventure to its open communications, but I'd like to focus on one in particular: its intolerance to bullshit. Google has a culture of intellectual honesty that focuses on what's right and what makes sense, rather than what sounds good. Things that do not go over well at Google: hiding behind titles or qualifications; grandstanding to make accomplishments seem more significant than they are; using vague jargon and industry buzzwords to cover an absence of real meaning ("the enterprise faces a tipping point in big data and must embrace advanced cloud technologies and end-to-end real time analytics"). 

     At Google, expect everything to be challenged. If your meaning is not clear, you will be asked to clarify it. If you're making a mountain out of a molehill, you will be cut down to size. And if you're talking a load of bollocks, you will be called out on it. Even if you're a Director. Due to their intolerance of bullshit, Googlers can be perceived as blunt or rude, but I perceive it as awesome. It's amazing the amount of difference a cultural intolerance to bullshit can make. It's like some sort of solvent that stops inefficiency and waste from building up in all the nooks and crannies of the organisation. Strategies are questioned and therefore improved. Dead weight does not make it into management. Pointless bureaucracy is squashed. The reality of the company's business and its own perception and projection of its business are kept in much closer sync when bullshit is eliminated. Trust grows, and politics shrinks. Good people don't leave in frustration.

     I've learned that I have a very low personal tolerance for the posturing and politics of bullshit. Therefore, I will value Google's low-bullshit culture even more this time around.

    The management

    I know that a lot of people think that the quality of management doesn't make much difference to a work environment, but I think otherwise. There are always bad apples, but on the whole Google has an effective and responsive management organisation that is dedicated to helping individuals and teams achieve their goals (and I'm not just saying this because I used to be one of them!). Clear communications are valued, and problems taken seriously. Leadership is by example, not by authority. If a team is unproductive for any reason, the manager of that team sees it as their problem to help improve the situation. Technical managers are drawn from the technical ranks, so they are never clueless PHB's and usually have their teams' respect.

    Part of what enables this excellent management culture are the frequent opportunities people have to provide feedback on and to their managers about their performance. This helps keep managers accountable up the line, but more importantly provides valuable input that helps them do their job better. As a manager, I often felt that people wouldn't tell me directly if they felt I wasn't doing a good job on something. The existence of various forms of structured and often anonymous feedback gave me great insight into what I needed to to better. Likewise, I made sure to always put thought into how I could provide valuable feedback to my own managers.

    In summary: managers were less like "the boss" and more like a part of the team whose job it was to make sure you were happy and productive.

    UPDATE: The second half of this article is now live. Click here to continue through to it.

    Posted by
    Labels: google opinion software development work
    4

    View comments

    1. Welcome back! It's not as idyllic as you remember it though :-) It's a great comparison and reminder.

      ReplyDelete

    2. Now I'm afraid of the outside world ;)

      ReplyDelete

    3. Welcome back! Also, you should try enabling g+ comments on your blog from the blogger dashboard!

      ReplyDelete

    4. That’s truly interesting post. Even I am going to attend the online marketing classes so that can be able to promote my small business. Recently I am availing only the facebook ads services but will start the SEO and PPC campaigns on my own. Hoping to find a good course that can help me learn everything from scratch.

      ReplyDelete

  7. Once in a while something goes crazy in my Google Reader (I know, time to find something new :-/ ) and it will spam my feed with dozens of old posts from one or other of the various blogs to which I've subscribed. It can actually be quite nice, as it gives me an excuse to trawl through the blog and reread old classics. Anyway, this recently happened with Steve McConnell's 10x Software Development blog and I was particularly taken by this old post on technical debt and how to handle it.

    While I've found framing software development and maintenance decisions in terms of technical debt to be useful for quite some time, Steve's post made me realise that the analogy of technical to financial debt is richer and more accurate that I realised. In particular, these two main points were really driven home:

    • Technical debt must be serviced. In other words, the main characteristic of what makes something a technical debt is that it incurs future work just to keep things running. So, just like real debt, technical debt is about taking from the future to satisfy the present. Taking on a technical debt may increase your development velocity now, but at the direct cost of slowing your future velocity until the debt is cleared or you declare bankruptcy (abandon the system in question). Anybody who has inherited a project that is impossible to maintain will intuitively understand how this kills the possibility of meaningful further development until a major refactoring/rewrite is undertaken to "clear the debt".
    • There are different types of technical debt, some of them 'good' and some of them 'bad'. With financial debt, 'good' debt is generally taken on either in order to invest in a productive and appreciating asset, or to invest in increasing productive capacity (e.g. borrowing to build a business). 'Bad' debt is debt incurred on depreciating or non-productive consumption (e.g. borrowing to buy shoes). Similarly, 'good' technical debt might be necessary to allow certain startup projects a chance to emerge into the light, whereas 'bad' technical debt is simply a cycle of slowing productivity and decay caused by poor planning and discipline. For example, taking on technical debt in dribs and drabs through sloppy development practices is nearly always a bad idea. By contrast, taking certain architectural shortcuts that allow a faster release in return for having to refactor several years down the track may be tactically wise.
    The blog post doesn't specifically discuss the concepts of principal and interest as they relate to technical debt, but I think the analogy stretches to these too. In the technical context, the 'interest' is the price that has to be paid just to keep things functioning in the presence of the debt. The 'principal' is that amount of work that needs to be done to clear the debt entirely. Paying less than the interest rate may be possible for a while, but just like with money this will mean that a yet greater debt accrues, requiring greater servicing and an even larger ultimate repayment. This is how many projects grind themselves into complete stasis.

    With this fuller understanding of the mechanics of technical tradeoffs, I feel it should be possible to both make better decisions (is it more important to get the product launched this quarter even though it means that two years down the line, it will be less developed than if we'd taken our time?) and to better quantify and communicate the effects of that debt to others, especially those of a less technical bent. Understanding debt and its tradeoffs has always been central to keeping a business (or one's own finances) on a good trajectory; using similar thinking can hopefully help people keep their technical project on the right track too.
    Posted by
    Labels: software development technical debt
    3

    View comments

  8. There are a bunch of refugees on hunger strike at a detention centre in Melbourne at the moment, and here's why: they were assessed as legitimate refugees by the Australian authorities (meaning it is not safe for them to return to their home countries), but then they were assessed as 'security risks' by ASIO, meaning they have been denied visas and are not allowed to be released into the community.

    Some of the refugees have been in detention for four years. Some of them have children. All of them have experienced Bad Things. None of them have committed a crime in Australia. They do not have the right to know the full reasons for their adverse security assessment. They do not have the right to appeal the assessment. Under current government policy, there is no process that will lead to their release.

    Kafkaesque, isn't it? Murderers have more rights than these refugees. Rapists have more rights. Paedophiles have more rights. These refugees are being locked up forever due to covert allegations of thought crimes. There is no possible interpretation under which this is something a civilised country would do. It seems to me that the current legal situation for these refugees is as bad or worse than the inmates of Guantanamo Bay.

    What's unbelievable is that both sides of politics support the current policy of indefinite detention. There's a kind of competition on between the parties to see who's "tougher on illegal immigration" and this seems to mean that human rights go out the window; international conventions be damned.

    Ah well, at least the economy's going OK.
    Posted by
    Labels: politics
    0

    Add a comment


  9. This is a follow up to my previous post about being lazy. In the last post, I tried to define laziness in a positive (or at least, less negative) light. Now here I'd like to talk about how to work with -- and even take advantage of -- laziness in order to succeed in one's career and other forms of work.

     Just as a reminder from the previous post, I like to think of laziness as a value-neutral description of my temprament. My default state is one of idleness, and I have to make an effort to do productive work. Working makes me tired, and I need enough time to recover after doing hard work before undertaking some more. I cannot stay productive beyond a certain point. This doesn't mean I don't care about getting my work done, or that I'm not productive when I'm working, but simply that working makes me tired and there are limits to how much of it I can do.
    I have always looked on with wonderment at people who are able to work 80 hour weeks, do all-nighters, work weekends, go years without taking a holiday, and so on. Again, I'm not making a moral judgement here: whether or not I think working 80 hour weeks is a good thing to do is beside the point. I would simply be mentally and physically incapable of pulling it off. I've never pulled a working all-nighter and can confidently say that I never will---I would fall asleep well before the sun rose!
    High energy levels, or whatever term one wishes to use to describe the opposite of laziness, often seem to be disregarded as an ingredient in the successful modern knowledge worker. Being smart is good, being educated is important, communication skills are valuable, good leadership skills are critical, and so on. But say you're an all-rounder with all these marvellous skills and attributes---how far can you get if you are only able to exercise them for 40 hours a week? Is there a glass ceiling for lazy people? This question vexes me, because I do see myself as somebody who could never work far beyond that 9-to-5 plus or minus an hour or two.
    I think there's good news here, though. Very few people are genuine all-rounders who are extremely strong in all ways. Some people lack a deep technical understanding of their chosen business, others are poor public speakers, and yet others may have a physical ailment that affects their work. Yet all these people are still able to succeed by acknowledging their strengths and weaknesses, compensating for the latter with the former, and putting themselves in a position where their strengths are strongest and their weaknesses are least significant. By treating laziness as just one more component of every worker's uneven profile of skills and abilities, and intelligently structuring your career and behaviours to minimise its impact, career success should be entirely attainable without working beyond your natural capacity.

    And, indeed, I am reasonably satisfied with the progression of my career thus far. So here, dear lazy readers (if you can be bothered reading this), are some tips and tricks I've picked up over the years:
    Don't be so hard on yourself
    First of all, you need to liberate yourself from the notion that being lazy is a moral failing. It's simply part of who you are, so work with it rather than fighting against it. I found that nobody judges you as harshly as you're likely to judge yourself. Excusing myself from 11:00 PM meetings where my attendance was not essential with the explanation that it would ruin me for the next day have always been accepted on face value, and not as a sign that I'm shirking. And of course when I sneak out of the office at 5:30 in the afternoon I can feel everybody's eyes on me... except that they're not, they're focused on their screens where they always are. Other people absolutely don't give a toss what time I leave, as long as they can see that I'm dedicated to my work while I'm here. This goes too for and good manager. A manager who cares about "chair time" more than productivity is a bad manager and to be avoided for more reasons than just this.
    Be clear and assertive
    Don't play games. Let people know exactly what your capabilities are and what you are willing and unwilling to do. I've found this to be particularly effective when being offered a new role. Remember, if your manager is asking you to take on more responsibility, that's because they think you're the best person for the job. They don't want to be turned down (they'll just have to find someone else, and they've already decided they'd prefer you) so you're in a reasonable negotiating position. In this situation, simply explain what your limits are and that you'd be happy to take on the role so long as the manager understands where these limits lie. Something like:
    "Thanks so much for offering me the role, and I'd love to take it on. I think you should know that I need my rest to work effectively, so I need to maintain a work/life balance. I don't think I can travel internationally more than 2 or 3 times a year, and I'll have to limit the number of late-night calls in which I participate. As long as that's OK with you, we can go ahead."
    This does not make you sound like you're whining or pleading. It makes you sound like an honest and upfront individual who knows their own needs and limits; exactly the sort of responsible person every manager wants to have on their team. I've never had an offer withdrawn simply by stating that I expect to have a life outside the office.
    Once you've established your limits, be protective of them. My strategy for evening calls, for example, has been to have them all stacked on one or two nights of the week and to keep the rest clear. Then if something is scheduled on an off night, I simply explain that "I can't do calls on a Tuesday evening". Again, I've never had a negative reaction to a polite request to reschedule a meeting.
    Another thing about being assertive: politely turn work down once you have a full workload. Quality of work is more important than quantity, and reliably delivering work on schedule is more important than being the nice guy (or girl!) who never says no to a request for help.
    Start early
    I don't mean come into the office early (although you can do that if you like), but rather that you should start projects early. If you know you can't ramp up your hours right as you approach a deadline, don't put yourself in a position where you might have to.  Pace yourself, be organised and you'll find that you can still deliver work on time. In fact, by adopting this strategy you can end up looking like a model of organisation and tranquility among your stressed-out midnight-oil-burning colleagues.
    Don't take on roles that you can't handle
    I like to think that as a lazy person I have many options in terms of the career choices I make. However, that doesn't mean that I'll take on a role that is fundamentally incompatible with my abilities. Again, this is the same for laziness as for any other aspect of one's personality. People who hate public speaking should avoid roles where they spend most of their time at a podium; similarly, lazy people should avoid roles where late nights and copious business travel are core requirements (real, not imaginary) of the job.
    Delegate and coordinate
    Many diligent workers avoid delegation because they think it makes them look bad or places an unfair burden on other people in their team. I don't see it that way at all: if you're working as part of a team, you owe it to everybody to do the best possible job you can. If you have more work than you are capable of handling, you will not do the best possible job. Plus if you're a team lead, you'll look like a control freak who's hogging all the responsibility. Don't do that. Instead, evaluate where there is work on your plate that would be better handled by somebody else on your team, and politely ask them if they'd be willing to look after it. More often than not they'll actually be flattered that you thought of them and excited by the prospect of extra responsibility in the project.
    Ride the waves of your energy
    As a lazy person, sometimes you feel like you can move mountains, while other times you'll feel quite lethargic. Don't try to do very taxing work when you're not up for it. What will end up happening is that you'll procrastinate and not get anything done at all. Better to keep a cache of mundane work available at all times (filing expense reports, tidying your desk, answering non-critical emails, chasing up procurement for the tenth time) and to tackle that work when you're not mentally equipped for the harder stuff. Conversely, don't waste your mountain-moving energy on crap work. Find the hardest thing on your TODO list and smash it!
    Go home when you're no longer productive (if you can) 
    In many roles, employees are measured on productivity rather than on time spent sitting at our desk. Thus, it follows that if you are no longer productive you should go home. There's nothing more stressful than sitting in front of a screen with the realisation that you are good for nothing but procrastination. Go home instead and refresh yourself... you may be able to do some more work later.
    If you have meetings scheduled, or if you have a role where you are paid by the hour, or you work in a customer-facing role with fixed hours, you don't have this option, of course.

    Posted by
    Labels: introspection laziness personal
    0

    Add a comment

  10. Mark Cuban posted a little article a while back about the parallels he sees between the newspaper industry and what is now happening in the tertiary education (university/college) sector. I've been making that same comparison for a while, but interestingly his analysis differs quite a lot from mine.

    Regardless, one does not want to be compared to the newspaper industry.

    In any case, I thought I would share my thoughts. Mark Cuban's analysis is a little US-centric, talking about how universities are taking on debt and increasing fees in order to invest in physical infrastructure  that is increasingly going to become obsolete... presumably because of the proliferation of online education institutions such as Coursera, Khan Academy, and whatnot. While this is no doubt true, I think that the comparison goes quite a lot deeper than that.



    The meteor that killed the newspapers


    Newspapers were hit by a one-two combo thanks to the Internet over the last decade or so. The first punch was that classifieds, newspapers' main revenue source, worked much better on the Internet than they did in print. In a short span of time, classifieds had migrated almost entirely to the Internet. In many cases, these advertisements were not appearing on newspaper websites, but on those of new and nimble organisations that were all about online listings and nothing at all about news. eBay, Craig's List and many others cut the newspapers' lunch, separating many of them from a critical source of revenue.

    But the bad news was just beginning. Even newspapers that were robust enough not to have to rely on classified advertising, or that were nimble enough to transfer their listings business online, now had to contend with the massively broader reach engendered by this new form of distribution. Back in the good old days, if you lived in Melbourne you had a choice of Melbourne newspapers and that was it. Rich fancy-pants types might occasionally pay $15 for yesterday's copy of the New York Times that had been air-freighted in. The costs and logistics of physically distributing the relatively bulky newspapers ensured that local markets retained their integrity, and every major city could safely sustain at least two or three major newspapers. The Internet took down the barriers that kept newspapers' markets local. Suddenly, I could go online and have a choice of The New York Times or The Guardian, as well as the Melbourne Age.

    Newspapers are a broadcast medium and now that they are online, they are dominated nearly entirely by fixed costs. Such a situation naturally favours economies of scale and a small number of dominant players. Why would I want to read the world news in a midrange paper like The Age when I can read the very best online for the same price? Very bad for medium-sized local papers, many of which have closed down or become shadows of their former selves.

    Notice that I've not mentioned the removal of barrier to entry as one of things that have killed newspapers. With some notable exceptions, predictions that newspapers would be rendered obsolete by a flood of amateur blogs have not come to fruition. Newspapers are being killed by other newspapers--and, one could argue, by Twitter--not by Joe's Blog.

    Something has been lost to cities that no longer have a serious newspaper. Real analysis of local politics, world news delivered from a local perspective. Somewhere for local thinkers to have their thoughts aired to a wide audience. A local narrative. The culture of newspaperless city is no doubt diminished.

    Why universities are like newspapers and how they can save themselves


    Anyway, back to universities. Of couse all analogies are rather imperfect, but to me it's easy to see a similar one-two coming at them right now. The first punch is the nimbler organisations (Khan Academy et al.) that are taking advantage of the educational possibilities of the Internet faster than traditional universities are doing. This is starting to take some of the growth opportunities (for example, in developing countries) away from established universities. Number two is on the way: turning education into a global online marketplace. Stanford have already started experimenting with massive online courses. Now in the future, a student might wonder why they're doing their undergraduate course with whatever lecturers their local university is turning out when they could be studying at Stanford or Cambridge online with the best lecturers in their field. Not good for medium-sized local universities.

    Now, unlike for newspapers, there is something universities can do about this. The analogy between newspapers and universities holds primarily because they both behave like broadcast media, which with the Internet means tiny marginal costs and a "tipping" process towards the highest-quality providers. I believe that for the high-volume undergraduate part of the university (i.e. where the money is), the broadcast analogy holds true. Teaching is focused on a lecturer model with very little student interaction; tutorial classes are focused on supporting the lectures and are not the primary product.

    In the future, local universities will have start providing a much more personalised and interactive experience for their students if they want to maintain their physical advantages over the Ivy Leagues and Oxbridges of the world. In other words, they must become true Teaching Universities. Second-tier universities that follow the traditional model of focusing all the love on research will lose students and find diminishing into research institutions rather than full-fledged universities. Which is fine, of course, as long as they are able to sustainably fund themselves as such. But undergraduates can no longer be taken for granted; continue to treat them as cash cows who can be herded through one-size-fits-all courses and they will desert you.

    I think that local universities are worth saving. Like newspapers, they are part of the civic life of any major city. A city without a university has lost something essential. Even if just as many of the population continue to be university-educated, all of the secondary functions of the university (cultural and political vanguard, formative experience for young people, etc.) will be lost. Furthermore, without a funnel to take high-school graduates and place them within a vibrant research scene, innovation is threatened.

    Universities have the chance to improve teaching and give this story a happy ending, or they can do what hidebound old institutions usually do, which is change far too slowly or in the wrong way. That story never ends well.

    Oxford. (Ron Hann) / CC BY-SA 2.0
    Posted by
    Labels: economics society
    3

    View comments

Blog Archive
Blog Archive
Loading
Dynamic Views theme. Powered by Blogger. Report Abuse.