Hacker News new | past | comments | ask | show | jobs | submit login
Rules to Lead by from the Man Who Defined Google’s Product Strategy (firstround.com)
78 points by ca98am79 on July 18, 2013 | hide | past | favorite | 12 comments



Great list. The only thing I'd add is 'Amateurs study tactics, professionals study logistics'. I've seen too many projects held up for want of a nail.

Anyone who's worked for a larger organization knows that you'll have weekly team meetings hammering on the developers to get project X out the door on time. Then the developers will walk out of that meeting and spend three weeks trying to get the tools and equipment they need from IT with zero backup from leadership.


>#4 Tell stories.

Great leaders are great teachers. And great teachers are great storytellers. “Narrative is how we learn. If you want to be a leader, you will teach and tell stories. The two are inseparable.”

When I hear this I can't help but think, narrative fallacy. Narrative may have traditionally been "how we learn", but recent research into biases and heuristics (Kahneman & Taversky especially) suggests it's not entirely reliable.

This bit of advice doesn't go into much detail on how telling stories is essential to leadership. Anyone have any experience on just what is meant here, and whether narrative fallacy is a concern?


> #1 Be a broken record. ... > #5 Stop talking, already.

Also, 42 rules? Would of been nicer to have just the few important ones perhaps.


> #1 Be a broken record. ... > #5 Stop talking, already.

Heh, I was going to comment on that as well. I think this shows something about the merit of taking advice at "face value" and not applying your own discretion and judgment to its application.

I also disagree to some extent with #10 and #13. What he calls "bustling" and "energetic" I call "distracting" and "annoying". And while I'm a big believer in the value of face-to-face communication, I think working-from-home has a role to play as well. The problem, in my mind (and I don't pretend to have a definite answer to this) is how to find the right balance between expecting people to be in the office, and allowing them the flexibility to work from home.


#5 would have probably been better stated as "Learn how to listen, already."


> #23 Don’t hire specialists.

I hope his definition of specialist is wrong considering that he himself is a specialist. Perhaps what he means is "hire people who can learn and adapt." After all, you won't get anywhere without people who have deep knowledge in particular areas.


#31 Consider the customer.

Seems google has gotten away from that. The Nexus 4 has a couple of very bad bugs that have gone unfixed for a long time. I feel really bad that I recommended a good friend get it, because these bugs have really damaged his enjoyment of the phone.


They've gotten away from it?? Here's a list of things they consider important, and #31 is the customer. And it's not even that strongly worded.. it's 'consider' the customer. In fact it says, "If there’s a doubt about what to do, consider your customer’s perspective." Literally saying the customer is an afterthought, only to be considered if you aren't sure what to do.

It doesn't sound like it was ever very high on their list to begin with.


Google seems to define "customer" differently than just "user": a. User of product that is strategically important to Google b. User that will still be heavily using that product in the future - often superusers/heavy users that are committed

So who wouldn't be a customer? a. Google Reader user (and similar products) b. YouTube or Hangout user not willing to migrate towards G+ c. User not willing to migrate towards centralized, single identity

So the long version of #31 might read "consider the long-term, strategically important (to Google's future) customer"

Overall, this is a great list though.


#10 Crowded is creative. #13 Show up.

I couldn't say I agree. It flat out dismisses companies that do perfectly well while having remote teams. I guess it depends on if you have a company that focuses on discussion more than say building something.


Lots of valuable one liners in there. I think being at google though he missed a few that are too obvious to mention there.

#43 Start with something that works and then iterate often to improve.

#44 If your project involves engineering then involve the engineers in the product specifications, don't trust marketing or MBAs to do it alone.

#45 Simplify as much as possible.


What is a bad egg? How do you identify and purge the bad eggs while laying off the kill switch?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: