Thoughts on Product Management & Retaining Developer Talent

Tech companies are an interesting beast. Low barriers to entry mean that the “next hot thing” is always around the corner. Couple that with geek culture that is always lusting after the next awesome thing, and you end up with a company like Yahoo that goes from the hot place to virtually irrelevant in less than a decade.

So why does that matter?

Simple: Talent.

“Creator” talent (developers, designers, etc.) is undoubtedly key at any tech company. It is what allows a company to build their stuff. Most other industries have machines that build their stuff (cars, CPG, etc.), however developers and designers are core to a tech company doing what they do.

What I find myself asking is how to cultivate a culture at an established tech company where you keep talented, creative people but give them the freedom to create like at a startup.

The FrameThink blog recently covered how Facebook Ships Code. There were some excellent nuggets to dive into.

As of June 2010, the company has nearly 2000 employees, up from roughly 1100 employees 10 months ago. Nearly doubling staff in under a year!

At most companies, this would be a cultural nightmare. Not at Facebook:

All engineers go through 4 to 6 week “Boot Camp” training where they learn the Facebook system by fixing bugs and listening to lectures given by more senior/tenured engineers. Estimate 10% of each boot camp’s trainee class don’t make it and are counseled out of the organization.

After boot camp, all engineers get access to live DB (comes with standard lecture about “with great power comes great responsibility” and a clear list of “fire-able offenses”, e.g., sharing private user data)

This is a lot like people rushing a fraternity in college – you spend “boot camp” time having new employees buy in to way a company works. Contrast that where you get maybe half a day going over HR policies and then it’s pretty much up to the manager and group.

Zappos does the same thing, where they will offer their customer service people a fixed payment to leave on the first day.

This also means a company has to know what their culture is and be sure of it.

What’s really fascinating is how Facebook manages their engineers:

Resourcing for projects is purely voluntary:

  • A PM [Project Manager] lobbies group of engineers, tries to get them excited about their ideas.
  • Engineers decide which ones sound interesting to work on.
  • Engineer talks to their manager, says “I’d like to work on these 5 things this week.”
  • Engineering Manager mostly leaves engineers’ preferences alone, may sometimes ask that certain tasks get done first.
  • Product managers have a lot of independence and freedom. The key to being influential is to have really good relationships with engineering managers. Need to be technical enough not to suggest stupid ideas. Aside from that, there’s no need to ask for any permission or pass any reviews when establishing roadmaps/backlogs. ”My product director doesn’t even really know all the things I have on my roadmap.” There are relatively few PMs, but they all feel like they have responsibility for a really important and personally-interesting area of the company.

It’s all about incentives! Project Managers are incentivized to come up with cool and useful projects, and there is a free market to decide what gets built. But PMs also have to maintain great working relationship with the development teams. This helps eliminate the us vs. them mentality that develops at many big companies where development plans are driven by many different teams (Customer Marketing, Product Marketing, etc.)

It also means developers will continue to love their jobs, when they’re getting to work on great, interesting projects and move around. Their managers give them the space to grow and learn.

That’s what smart people want – probably more so than money or prestige. They like to work on interesting projects. That will keep them around as long as they’re challenged.

Engineers handle entire feature themselves — front end javascript, backend database code, and everything in between. If they want help from a Designer (there are a limited staff of dedicated designers available), they need to get a Designer interested enough in their project to take it on. Same for Architect help. But in general, expectation is that engineers will handle everything they need themselves.

Arguments about whether or not a feature idea is worth doing or not generally get resolved by just spending a week implementing it and then testing it on a sample of users, e.g., 1% of Nevada users.

No QA at all, zero. engineers responsible for testing, bug fixes, and post-launch maintenance of their own work. there are some unit-testing and integration-testing frameworks available, but only sporadically used.

Surprise at lack of QA or automated unit tests — “most engineers are capable of writing bug-free code. it’s just that they don’t have an incentive to do so at most companies. when there’s a QA department, it’s easy to just throw it over to them to find the errors.”

Again – more incentives. The responsibility lies on the developers to write great code. Eliminating a step (QA) also means faster roll out of code and cost savings that can be funneled into more development.

I don’t claim to know what it’s REALLY like in a development organization, but these are some fascinating thoughts. The incentives built into how Facebook works seem like a great way to retain talent. More than that though, it’s a very interesting way to build great projects and decide what gets funded. It ends up not being about the money, but instead, what’s interesting and relevant.

You have to assume that the free market for development time & talent will win out in the long run. I may be wrong, but it’s working for Facebook today. Other large companies might have something to learn from this Product Management philosophy. It helps retain talent in the process.

January 17, 2011