When people talk about Google ruling the roost, it’s common to compare them to Microsoft. I’m an old guy, and I remember Microsoft as our overlord. So I find that comparison pretty darn funny.

But if you haven’t been doing this since, oh, call it 2005… That doesn’t necessarily mean much to you. Microsoft? They’re not anybody special any more. Certainly they’re not unusually evil. They’re not especially powerful, even. Yahoo is probably as strong as current Microsoft, and Yahoo doesn’t intimidate people into anything.

What was Old Microsoft like that was so scary?

Old Boys

Microsoft specialized in a few specific things:

  • Packaging and contract-writing rivals to their core businesses (OS, Office) out of existence, often through straight-up illegal pricing.
  • Leveraging their OS and Office monopoly to bundle other products, killing rivals with ‘free’ included versions (e.g. Internet Explorer, leveraged to support their web servers, back when those cost money.)
  • Suing rivals out of existence, often just because it was more convenient than competing
  • Cozying up to small companies, hiring their primary engineers, cloning their product and folding it into Windows — even if the product was stupid in the first place. Amusingly, that’s how we got Clippy.
  • Out-marketing technically superior companies, killing them because they’d been outbid in the marketing channels.
  • Putting in MS-only optimizations into the OS and/or specifically putting in “screw this one other company” sabotage. Remember, everybody had to use Windows back then.

Google is a “Good Old Boys” style company like GM — “what’s good for General Motors is good for America.” In fact, you’ll literally hear Google folks say things like, “what’s good for the Internet is good for Google.”

Now, Google is an ad company and they act like it. But they’re in a wide-open space, they can literally make lots more money by getting more people using the Internet, and nothing they care about is particularly competitive. Blue ocean all the way.

This is much, much better than “carpet bomb potential competitors, eat young companies that might do well, sue and market everybody into oblivion” old Microsoft. Microsoft had a weird persecuted streak that translated into them being the big dog but believing mauling any little dog that they thought might get big.

Which meant if you were a little dog back in the days of packaged software, you had to get past a paranoid mortal rival (Microsoft) just to sell your software — everybody used Windows, so you had to deploy to a Microsoft platform. And I promise you, they played very rough sabotaging some of their competitors with the OS. There was no digital distribution platform. There wasn’t a browser you’d want to deploy to. Just the desktop.

Microsoft didn’t come down on everybody, but when they came down, they came down hard. You were always praying the they didn’t see your market as too profitable or too strategic. Only the biggest companies could fight them — and even the biggest companies couldn’t usually win, just fight longer before they sank.

Paul Graham (figuratively) sang a lovely little ode to the end of that era when he noticed it was over.

I recently wrote about good project managers &mdash and I mean it.

But there’s a particular project manager meeting that is usually a bad sign, a sign that you’re not dealing with a good project manager.

I’ll call it the “How You’re Going to Use JIRA” meeting. It doesn’t have to be JIRA, though JIRA is designed with this (awful) meeting in mind. It won’t be phrased quite that way, though that’s exactly what they mean.

To see why this meeting is bad, let’s look at a much better meeting — the Engineering “here’s an internal tool” meeting. Imagine a senior engineer sitting with (internal, usually) customers, explaining something they’ve just finished prototyping (or building) and showing off the various features. “Here’s the new XYZ workflow that you wanted” or “this is a new method of auditing ABC.”

In a good meeting of this type, you’ll alternate “yes, that’s what we wanted” with “that’s not quite right” with “uh, not sure what’s up with that” with “okay, we’ll try that, not sure if it’s what we want.” A good engineer will be taking notes to see which features get which reactions.

A good engineer will also understand that while you can explain a few things to the customer (“well, we actually intended…”), the customer is basically right. If your customer (paid or not, internal or not) says “no, we won’t use this”, you’re basically going to have to rethink the feature.

In other words, each feature is intended for the customer’s convenience, and if the customer disagrees about his/her own convenience, s/he is right and you, the designer of that feature, are wrong.

Now let’s talk about Project Manager Meetings.

When your project manager comes to you and explains the (invariably complex) new JIRA workflow, s/he is presenting you with how you’ll be doing things. And if you disagree, the (un-checked) feature designer is right and you (the customer, who already does this) is wrong.

It’s like a customer meeting with engineering, except the engineer is right and the customer is wrong.

Ever been through that literally? Like the engineering meeting above, but they’re allowed to tell you how to do it?

It’s marginally more pleasant for the engineers holding the whip, but it’s a really bad sign for the company.

It means that efficiency and in-the-trenches experience don’t matter, but the opinion of appointed people who don’t understand the work does matter.

It means that work is going to go badly from here on out.

Which, not coincidentally, is what it means when your project managers tell you how to do it for their convenience, too.

Recently Chad Fowler wrote a great job description for a software engineer. I replied that a person like that is currently un-hireable in Silicon Valley.

Another fellow asked me, how would I change the list for technical instructors rather than straight-up engineers?

And if they offered something like 20% time to let somebody keep their skills that sharp, what are the really key components of that program?

Those are great questions. Here’s how I answered:

I’d have nearly the same list of qualities for a great instructor. It might change which items were most important — teaching and learning are obvious choices to put higher on the list, clearly. But that list is already focused on somebody who is big on communicating and instructing, and that’s part of why it doesn’t feel like standard developer job descriptions.

A lot of what killed 20% time at Google was that it was at manager’s discretion. And “at manager’s discretion” turns instantly into “is awarded politically.” As went around on Twitter recently, most things at Google (and to be fair, elsewhere) are like that, which is why Peer Bonuses have the same problem. They’re at manager’s discretion, so they can be turned down by the manager. So they become power games.

Unfortunately, “don’t hire people who play power games” is a terrible solution to this problem, because everybody defines “power games” as “the kind of politics I don’t like.” Which means they have a huge blind spot for the kind of politics they benefit from. There’s not really a way around it. I’m not being holier-than-thou, for the record — my blind spots are as big as anybody else’s.

To answer your question as directly as I can: make 20% time sacrosanct. Don’t give recommendations on what to do with it, don’t require a focus on a technology being taught, don’t make it conditional on performance (and “performance” is a highly political and subjective thing, alas.) You can consider requiring some kind of report on what was done. But even that can be abused, and most people have blind spots about how it’s abused.

Basically, make it very hard for managers to pressure people to work in particular directions with 20% time. The problems with that are the worst with the employees who fit in the least — who tend to be disliked by their managers, who tend to be called “not a culture fit”, and who tend to have the most actually different ideas. Those, in other words, with the greatest potential benefit to themselves and your company from 20% time.

They are also the ones that your smartest employees look to as a bellwether of whether you’re cracking down — whether smart people need to “look productive”, which is usually the enemy of “being productive on the important stuff.”

Managers dictating terms also makes it clear that 20% time is part of the standard company work. That would mean it’s useless for reinforcing most of what you want for the employee described in the blog post. Much like current Hackathons, you’re making it clear that it’s for the company’s benefit, not for yours. Except the company needs a bunch of stuff that isn’t (directly) for its own benefit from employees like the ones in the blog post. 20% time becomes one more thing added on top of your current job description, not a way for employees to feel okay about expanding their own competence outside of current business goals.

And as I wrote in my response, Chad Fowler’s job description requires doing three or four full-time jobs. Anything else you add on top of it is going to seriously reduce the applicant pool. 3-4 jobs’ worth of skills is ridiculous, the equivalent of “I only date ballerinas over 5’10” with a Ph.D.“ You’re also requiring people who are, by their nature, perfectly capable of starting their own company, which pays much better on average than you’re willing to, and comes with way more respect.

The 20% time I have described is clearly not doable at almost any large company. It requires making a lot of managers act against their natural inclinations. When you have something “fun” like 20% time, why would you not use it as a reward and motivator?

(For the answer, look up “intrinsic motivation” or watch the Dan Pink TED talk.)

20% time is valuable because often your company is doing many of the wrong things, and smart employees can fix that somewhat. Which means the more it’s affected by your existing culture, the more of the advantage you’re throwing away in favor of conformity.

Managers are in the business of generating conformity. Also of reducing risks, increasing repeatability and increasing consistency. In other words, they specialize in all of the mortal enemies of 20% time.

(Don’t get me wrong. The results of 20% time can be help those same things. But 20% time itself is a highly creative activity, and dies from repeatability, de-risking and extrinsic motivation.)

Recently, John Sonmez wrote about software development, and specifically claimed project managers don’t tend to do anything useful.

To be fair, sometimes he’s right. And you always have to watch out for “meta-work” — telling people what to do instead of doing things.

But I believe project managers are necessary — they just don’t do what John thinks they do. As an engineer, you’re the project and not the customer for them. This should make sense to you – you’re not paying their salary. And if you’re not paying for a thing, you’re the product, not the customer.

A business has to make technology decisions. They have to know “when will it be done?” and “how well will it do the thing it’s supposed to?” As a software engineer, you want the answers to those questions to be “it’ll be done when I say it is” and “it will do it perfectly, or at least as well as I can make it do it until I get bored with that.”

Those are unsatisfying answers to a manager who has to coordinate a marketing blitz with your technology release schedule.

The project manager is a way of slowing down engineering slightly (a significant cost) in order to know more about how well they’re doing, when they’ll be done doing it and how well it will work afterward (an enormous benefit.)

Note that the cost hits you too (you lose velocity) but the benefit is entirely to “business guys” you don’t particularly care about, though you should.

As a software engineer, you are the product rather than the customer when it comes to project managers and related tooling (e.g. Jira, Pivotal, nearly any “agile tool.”)

However, the tradeoff is actually a good one. The company will be a lot more successful if the business guys can make good decisions around your software quality and release schedule. And we do not traditionally give them the information necessary to do that accurately and on time.

If your startup does certain things, you wind up with the same business model as Yelp. It turns out you really, really don’t want the same business model as Yelp.

Not the same Emma.

Let’s tell the story of the fictitious Emma Goldfarb founding a seed-stage startup called Review.ly (unrelated to the URL shortener.) Review.ly is going to be a site where people leave reviews of some kind of business. Emma isn’t quite sure about the details. She’s working on it.

Spoiler: she’s in an ugly situation because her startup wants to be like Yelp… And she really doesn’t want it to be.

Follow the Money

Where does Emma’s money come from? Advertising doesn’t pay much, unless you have people who are about to buy something online in a trackable way. Emma doesn’t. Most of her reviewers have already bought their thing. Users looking for reviews are (in her case) not going to buy through her, so she doesn’t get paid that way. Some sites can avoid that, but Emma can’t.