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.

dubious search Hey, Ruby web developers! Having trouble asking deployment questions? Not sure what Provisioning or Orchestration are? Getting bad results Googling your questions, but not sure why?

Let’s go over some deployment vocabulary from your point of view — that makes it a lot easier to Google and to read information about deploying your app to a server, and setting up that server in the first place.

As a nice side effect, you may have an easier time talking to your Ops guy at work.

First, let’s go over what the word “deployment” means:

Deployment

‘Deployment’ is the process of putting a new application, or new version of an application, onto a prepared application server.

If you are talking to a developer, it may also mean the process of preparing the server, perhaps by installing libraries or daemons. If you are talking to an operations professional, it DOES NOT. They use the word “provisioning” for that.

(Developers are going to keep using the word “deploy” for everything involved in getting our app and its dependencies installed. That’s cool. But don’t be surprised if you confuse your Ops guy.)