Justifying your dream job

Justifying your dream job

Summary: Is giving your employees their dream job going to help or hurt the bottom line? One manager responds.

TOPICS: IT Employment

One responder to the article I wrote on "My dream job", a manager at a large software company, called it "selfish". We communicated back and forth, and the exchange was interesting so I want to share some of it. I've taken some liberties with paraphrasing, but this is the gist of our conversation.

"Where's the benefit to the employer?", he wanted to know first.

I thought the benefits would be self-evident but perhaps not. They includeWhat's good for the employee is good for the employer. satisfaction, loyalty, self-improvement, quality, encouragement, productivity, respect, honesty, collaboration, quickness, flexibility, camaraderie, and pride. It boils down to this: what's good for the employee is good for the employer. I cited Google as an example of a company that embraced some of these ideals successfully.

"Do you really believe Google allows their employees 20% of their time for doing whatever they want?", he asked. I've talked to several Google employees and it seems to be true (see here, here, and here). Pursuing your own projects isn't just "allowed", it's encouraged as part of your job. "But what if they spend that time," he worried, "on things unrelated to their main project?". That's kind of the point, I replied. Sometimes the best ideas come from unexpected places.

"Suppose one of them didn't buy into the idea of spending times researching other things," he countered, "and they used all their time on their main project. Wouldn't they have an unfair advantage?"  His thinking was that if people saw their colleagues focusing only on their assigned jobs and getting ahead, then everybody would want to do that; nobody would want to "waste" 20%. I argued this wouldn't be a problem, that anything learned while doing "other stuff" could only help. Besides, if you carried this to its logical conclusion, then constantly putting in overtime would lead to increased productivity. It's pretty widely accepted that's not the case. Sometimes you just need to think about something else for a while.

One of my points in the article was that developers should be responsible for the quality of their code. "How can you assure quality like that?" he wanted to know. "Surely they have some process in place for verifying fixes before they get committed." By that he meant code reviews, mandatory regression tests, talking it over with the testing group, getting approval from the test lead, etc..

I countered that many successful open source projects use a process of meritocracy. Developers earn the trust of their peers over time, and (except perhaps in a cycle's endgame) should be able to push whatever code they feel is needed. If you don't trust these committers, then they shouldn't be working on the project. If they screw up, then it's their responsibility and they've got to fix it pronto. See also Ryan Lowe's comments on this.

You can always vote people off, at least on reality shows and open source projects. Unfortunately it's not that easy in your typical workplace. If only our dream jobs came with someone like Lilo, who could find the one perfect place for everyone...

Topic: IT Employment

Ed Burnette

About Ed Burnette

Ed Burnette is a software industry veteran with more than 25 years of experience as a programmer, author, and speaker. He has written numerous technical articles and books, most recently "Hello, Android: Introducing Google's Mobile Development Platform" from the Pragmatic Programmers.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Take a finance course (or study it up on the web)

    At least half the people involved in the evolution of our product can just as easily talk about ROI / NPV / IRR etc than variations of the GOF patterns / servlets / etc.

    Which is probably why (as per my post on your "Dream Job") we have many of the things that you enumerate. And the conseqent increases in productivity that go with that. Of course you also missed one being flexible work hours - work from where you want, when you want, as long as you're not completely isolated from everyone else.

    If you can both understand the financial driving forces, and talk the right language in explaining why something is a good idea (then back it up with the calculations...) then you have a great chance of getting it implemented.
    Until then the risk adjusted discount factors will kill you when you try and explain the definate cost away against the unquantified productivity increase.

    Karl Laird
    Solution Architect
    OrderWare Solutions
  • Google is an ad distribution service...

    ... which runs a search engine to attract people to the ads. Very successfully.

    But the revenues received have attracted the attention of major competitors, and Google cannot continue to succeed at its current rate. Particularly the rate of growth.

    Google's current high stock value is not the result of people believing Google will hold its own. Revenues are expected to grow.

    So what can Google do?

    One solution is to hire talented people and get them to think about new ways to gain revenue. Hence, I think, all the free time.

    If a company already has its goals and projects to reach those goals, I expect that the time allocated to the irrelevant would be substantially reduced.

    And, in a large company, that some people hired for the purpose would be spending full time on distant products rather than only part of their time.

    Give Google time to be under pressure. Then you'll see the same system arise as at any other big public company.
    Anton Philidor
  • Predictability vs Productivity

    One thing most people miss about processes is that the intent usually is to make the business operate in a more predictable manner, not a more productive or efficient manner.

    Open source is hardly predictable when it comes to release schedules, and by inference it's not predictable in terms of man hours spent on a release.

    So open source models don't really work in a commercial environment. When your customer loses money because of a bug in your software, are you going to tell him: "Well, we're really are sorry. The bug was in Bob's code, and he's lost the respect of his peers. The team has revoked his committer rights. By the way, the next release will be a month late because of the time required to review Bob's contributions."
    Erik Engbrecht
    • Open source can be predictable

      "Open source is hardly predictable when it comes to release schedules" - There are several good examples to disprove this statement. For example, Eclipse is famous for predictable releases - a milestone every 6 weeks and a full release at the end of June.
      Ed Burnette